Tips for Domain Driven Design
Domain Driven Design is a powerful technique for building complex business systems. Emphasis is placed on understanding the business domain language (commonly referred to as the Ubiquitous Language). The result: a clear and common understanding of key business knowledge.
Overall, there is greater clarity during the design, development, and maintenance phases. Here are some tips to help you through the process:
1) Don't start with the User Interface
Ask the question "What is the problem?", instead of "How will the user solve this problem?".
This subtle difference keeps discussions focused on the business domain, user stories, and key business concepts. The resulting model will provide much more insight than a User Interface.
2) Design domain models, not database schemas
Stay focused on thinking about domain entities and their responsibilities - not database tables and relationships.
Designing databases directly from user stories may feel natural, but will produce an unnatural domain model that doesn't fit with the Business User's mental model.
Don't worry that the database is being forgotten - you can use TrueView DataBridge to generate database schemas directly from your domain model.
3) Design your domain model incrementally
Defining too much detail during the initial design stages is the fastest way to get side-tracked.
Try to understand the domain model at a high level. Pick out concepts from the user stories, and use them to identify Entities that have a natural place in the business domain. Add more detail as you drill further into the user stories and requirements.
Remember: the domain model should complement your user's understanding of the business.
4) Get constant feedback from your Domain Experts
Ensure that your Development team and Business Experts have a common understanding of the domain.
Constant feedback is a core tenet of the Agile development process. Take advantage of TrueView’s auto-generated prototypes - demonstrate your domain models and get instant feedback wherever possible.
5) Separate business concerns from technical concerns
Certain aspects of you applications fall outside the realm of the business domain:
|
|
Writing code to handle these aspects is serioulsy time consuming, and can be counter-productive during the domain modelling phase. Try to defer these activities until the domain model has stabilised, and you have a good idea of what you’re building.
6) Unit testing wisely
Creating too many unit tests could hamper development (and potentially future maintenance).
Create unit tests when requirements are understood and fairly stable, and focus on testing non-trivial behaviour and complex business logic.
Consider using frameworks such as NBehave to create comprehensive tests for your user stories.
7) Think agile, be agile
Finally, choose technologies that support fast development and reduce maintenance overhead. Your clients don't have time to wait, so don't make them.