Design vs Coding, and DDD

I have the chance (some would probably not call it that way) to deal with architecture/design stuff in my work, in addition to doing real coding and hands-on development work during my consulting activities.

For me, it's sort of an experimental way aiming to find which of one of these two would fulfill my day the most. After doing the two for the past 2 years: I came up to the conclusion: the mix of both is what fits me since coding allow to stay more in touch with the technical aspect and the technology while the design and architecture helps me keep some perspective as to which technology can make some difference and which adds up to ... well mostly hype!

An interesting approach that I find in OO-type of development that actually stresses the importance of having both competence in order to build complex system having all usual quality indicators. This approach originated from Eric Evans and is now well accepted and referred to as Domain-Driven Design (or DDD). I will not describe it here, please refer to his book.

However let me just comment of one aspect that I find particularly useful during OO design of a typical business application. It really helps in producing well organized, well designed, well documented and logical Domain Model construction. Very briefly the way I see this particular concept, is similar to a form of taxonomy that helps you organize and classified each object that you design in your Domain Model based on their roles:

• Entity Objects are those with a very precise identity and transactional lifecycle, and for which we usually worry when multiple instances of the same identity could be found at runtime. They would typically be mapped to a unique row in the persistence database.

• Value Objects are those without any identity where its field attribute are only compared by value (i.e. two instances with same value are considered equal).

• Factory Objects are those concerned with the creation of object(s)... more often justified when creating group of objects along with their associated graph. This is required when this creation involve enough complexity to warrant encapsulation through factory.

• Service Objects are those used to handle and implement business service along with associated business rules. These service objects usually operate on multiple collaborators entity objects as well as their repository.
  

• Repository Objects are those used to handle entity lookup and persistence through an abstract layer hiding any details and idiosynchracies of the related persistence engine. They are typically used by Service objects, but sometimes by Entity Object, in which case Entity object would have a reference to the Repository passed inside its methods requiring Repository functionality.
  

I find this taxonomy very insighful and convenient, and this is certainly useful to adopt..still worth it when only used to help standardizing design terminology among developers and architect!


Martin