A good domain model focuses only on the relevant details and ignores the rest. There are several ways to communicate the model. The book explains some of the techniques covered by the book Domain Driven Design by Eric Evans.
They are :
- Ubiquitous Language
- Layered Architecture
- Value Objects
- Entity Objects
free copy of the book from info site. I will briefly go over some of them in the context of Rails
We need to find those key concepts which define the domain and the design, and find corresponding words for them, and start using them. Some of them are easily spotted, but some are harder.
In the Code Review session by Marcel Molina and Jamis Buck Aggregates, they show an example where Aggregates is put into practice. They call the Aggregate as the Super Model.
I worked on a Rails project where the User model become bloated with attributes that could be extracted into its own model. For instance, address, contact info, billing info etc. So the User model is
Development Process and Domain Driven Design
I have experienced this on a project where the team was doing TDD and due to simplistic design the code was brittle. The team did not spend much time on design. It seemed like we were going back to
square one once every couple of weeks. The overall productivity of the team went down.
It talks about implicit concept, constraint, process and specification. It provides practical tips on how to refine and improve the initial domain model. I really liked this section of the
Creating the Model
The alternatives are :
1. Create a set of small diagrams with text that explains some aspect of the system which cannot be represented by the diagram. The diagrams can be hand drawn. In the initial stages the domain model
changes a lot, so this is a practical approach.
2. Communicate using code. This is the XP approach. Use well written code as the communication tool. In this case you don't have the problem of documents getting out of sync with the requirement
The book talks about the Analysis Model and the Design Model and how there is gap between these two models. The developers have to deal with the implementation issues that cannot be foreseen by the analysts.
very cohesive model that is as small as possible.
If required, you can split your application into several applications that have its own domain model. For instance if you have a web application that is about outdoor adventure club management, you can split the billing system into a separate application. This allows the billing system to be used with any system.
I agree with other bloggers regarding the way the Rails team integrates those apps using ActiveResource. It is not a good solution. The ideal way to integrate them would be to use some kind of asynchronous messaging system. This could be as simple as a cron job.
Preserving Model Integrity
In the last chapter where Eric Evans is interviewed he mentions the pitfalls of domain modeling:
- Stay hands-on. Modelers need to code.
- Focus on concrete scenarios. Abstract thinking has to be anchored in concrete cases.
- Don't try to apply DDD to everything.