Use Case Driven Development
There’s a real advantage in solving problems by delaying the implementation details as late as possible. It allows us to concentrate on business logic by turning the user stories into use cases.
A user story is an informal, general explanation of a software feature written from the perspective of the end-user. User stories are a few sentences in simple language that outline the desired outcome. They don’t go into detail. Requirements are added later, once agreed upon by the team — wiki
An example of a user story is
As a registered user I would like to authenticate against my profile. The system should also lookup my user role. It should also retrieve the user role information which includes what features I am permitted to access
A use case is a technique for capturing, modelling and specifying the requirements of the system. A use case corresponds to a set of behaviours that the system may perform in interaction with its actors, and which produces an observable result that contributes to the goal of the user story. Actors represent the role that human users or other systems have in the interaction. — wiki
Continuing with the above example, we can convert that user story into multiple use cases.
- Authenticate profile
- Lookup user role
- Retrieve role information
Use cases hold business logic and would typically call code repositories/controllers which would hold and manage system logic like calling a data source to insert data, calling an API to send an email and logging records of events and changes.
Building business logic code components allow us to write code that is:
- Independent of Frameworks
- Independent of Database
- Testable
- Independent of UI
- Independent of External Services
Most of our innovation and creativity time spent should be on use-case business logic which is isolated purpose-driven code components.
Conclusion:
Allowing the end-user to be part of use-case code components development helps us, developers, to finalise business logic more quickly. It hides technical details and makes the client feel like they are a genuine part of the solution. Not only does the process help communication but also forces us to delay implementations that can be dealt with in isolation.
