I went to a hands-on tutorial today by Eric Evans on Domain Driven Design. It’s one of those less specifically technical areas that is harder to pull off, but Eric made a pretty good effort with about 30 of us.
Domain Driven Design as presented is primarily the search for a good domain model through a ubiquitous language. The end result is that writing the code should really expressive of the underlying domain. Something like:
billDate.month().end().plus(allowedWaitBeforePayment)
In English this easily translates to:
For the end of the month on the billing date add a certain number of days before payment is due.
It’s still Java so it has some syntactic noise that’s hard to avoid, but it is approaching more readable code.
Some key ideas:
- A model not reflected in the code is irrelevant. (ie MDA)
- UML should mostly be done messy on a whiteboard.
- Try to verbalize the concepts you describe in a model to eliminate awkwardness.
- Not a big fan of getter/setter.
- Primitive data types are bad. (float for money)
- Business people will not use your modeling tool.
- It’s OK tho have multiple models in different contexts if they have clear boundaries.
- Object reuse often hasn’t worked well because sharing objects across different contexts. A person object who’s an employee in your financial system doesn’t actually carry over to a person object in your CRM system.
The class was thought provoking enough to nudge me to pick up his book on Domain Driven Design.