The blog of Tobin

Tobins nerd blog on .NET, Software, Tech and Nice Shiny Gadgets.

Tuesday, December 21, 2004

Domain Driven Development


I've recently been reading Domain Driven Development (by Eric Evans). This is an excellent book I think, there's some really good advice to those looking for good techiniques to deriving their object models. In fact, I'm wondering if it's the best book I've read on the subject!


Eric recommends focusing on communications, and developing a single, consistent and ubiqoutous set of terminology with which all team players can talk about the business and the software. Furthermore, this language should be used in the code also, so that the domain model completely mirrors terminology that appears in business conversations. This sounds simple, but how many times do you find yourself naming classes in such a way that don't really reflect anything that's come up in conversation?


Today I started applying this technique on an existing code base, and the results are quite startling. Suddenly my domain model is looking much more understandable, because it completely reflects the concepts that myself and the client have been discussing and exploring. I can also see where my code is straying from the "real" business model, which tells me I have some work to do to bring it on track.


Another nice aspect of the book is that it describes a system of names for software designers. Eric talks about the different types of classes that can appear in and around your domain model. He gives us a set of object "types" that broadly abstract the roles your classes play inside a software system. Examples are:


  • ENTITIES: These are usually long lived objects that have an identity. They are usually persisted in a database of some kind.
  • VALUES: These are value objects that don't really have an identity, may be immutable, and are used for messaging or to describe aspects of ENTITIES.
  • FACTORIES: Rather than having complex initialisation logic inside ENTITIES, Eric recommends using factories to create them instead. This is basically the Factory pattern.
  • AGGREGATES: This one is a great idea. Eric recommends distingushing between entities that are "root" and those that are not.
  • REPOSITORIES: These represent root collections of ENTITIES. Basically save and load points.
  • SERVICES: Behaviours that do not belong in any IDENTITIES can be packed into services. He also talks about the difference between application and domain services.


Anyway, I won't waffle on. I thought this is a great book and would recommend it to all!

0 Comments:

Post a Comment

<< Home