Build by use case

On many projects, developers are included to build their software from the ground up, layer by layer. This is argumented by the developers stating that “we really need to build the database access layer first, otherwise we are unable to realize the domain layer”. So the software is built layer by layer.

There is a big risk involved in building layer by layer. This has to do with frequent feedback from the customer and the users. They will not be able to judge the software being built until the first user visible functionality is realized. Building layer by layer this ecstatic moment in time isn’t met until all layers underlying the user interface are fully operational. This might well be at three quarters of the project. Of course, this is by far too late.

Another drawback of this technique is closely related. Building the full layers, such as the domain layer or database access layer, you will need to know everything there is to know about these layers. That is, when constructing a fully operational domain layer, you will to know exactly which domain objects are required. Building the domain layer before any user visible functionality make changes to the domain layer, when user feedback requires so, very awkward. Or even worse, you could have built parts of the domain, spending expensive resources, on parts of the domain that will never be used.

To avoid this technique, in smart projects, we build the software smart use case by smart use case. Why? Well, any smart use case is a reflection of all layers in your application architecture. Typically, a smart use case runs through the following process:

  • the smart use case is started.
  • it initializes the functionality.
  • the smart use cases picks up any relevant domain objects from the domain layer. The domain layer employs any layers below to fetch the object. It might trigger a database interaction, or it could call on a service layer to grab data from any relevant external service, such as a legacy business service, a web service or an enterprise service bus.
  • the user interface, if present, is presented.
  • the user performs some actions, such as manipulating the domain objects.
  • the domain objects are passed back to the smart use case.
  • the smart use decided on further action. To this it again fires the domain layer, that will issue requests to underlying layers.

That is, during the execution of a smart use cases, it touches most or all layers in our software architecture. Now since each smart use case delivers functionality to the users, your software architecture gets tested each time, allowing it to improve and grow during the project – agile or evolutionary.