DDD Step By Step
A Practical Guide to Domain Driven Design

October 2008 - DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • DDD - Making meaningful relationships by Colin Jack

    A recent discussion on the DDD forum made me want to post about what I consider to be an under-appreciated aspect of domain modelling, namely relationships. In the thread Randy Stafford said the following: Note that RoleRegistration is an example of a Relationship Object – arguably a fourth archetype of domain object alongside Entity, Value Object, and Aggregate. I couldn't agree more with this, in a domain model I worked on recently we had a stack of very useful and very meaningful relationship objects that served a range of purposes. For example if a Client has Accounts then it is possible that you can get away with just having that as a direct relationship but its equally possible that the relationship itself is meaningful and carries its own data/behavior. In this case you might have a type association with the relationship that would explain if the Client owns the Account , or whethery just manage it, or whether they are actually just one of several owners. Aggregates You need to consider aggregate boundaries especially carefully when using Relationship Objects. In the case of an association between a Client and an Account the relationship probably belongs to the Client aggregate. Then again if you choose to model the...

  • What I want from an ORM by Colin Jack

    Thought I'd blog about some of the things I'd like to see in an ORM in the future, particularly to support DDD cleanly: No enforced associations - I never want to create an association in the model just to support persistence, regardless of where keys are stored. So if I want to use uni-directional associations then I should be able to do that without having to go for workarounds . Aggregate locking - Currently, with NHibernate at least, its difficult to lock an entire aggregate. For example NHibernate's optimistic concurrency approach involves applying a version to rows, however aggregates can span tables so we really want to be able to give each aggregate a shared version ( coarse-grained locking approach ). See coarse-grained lock pattern . Validating before saving - I'd like hooks to automatically and cleanly validate an entire aggregate before persistence. Disabling unit of work - I'd like to be able to disable my unit of work, in many cases when working with DDD the UOW becomes more of a hindrance than anything else. I really want to be 100% sure that the only way to save a Customer is through a CustomerRepository . Revalidate value objects when reloading - Value objects only validate their data in their constructors...

  • DDD and Complexity by Colin Jack

    There have been some interesting and entirely valid discussions on Twitter about the validity of DDD and about deciding when its useful and when its too complex (including good comments from Casey Charlton and Jimmy Bogard ). I full agree with Casey and Jimmy and the comments, when combined with an interesting discussion on the topic at the latest ALT.NET UK discussion, let me wanting to blog about how I think DDD can be used in different types of projects. First off I must admit that even for a simple business system I'd be thinking about using some of the patterns from DDD, in particular I think these usually have value: Aggregate Repository Service For example I find that thinking about aggregates makes me think much more carefully about how to map those classes to the database, for example how far to cascade, which in my view is a good idea as not thinking about boundaries can lead you to some fairly annoying debugging sessions. You can take these three patterns and with a good ORM and create and map a simple domain model to a green fields database very quickly. Tradeoffs Here's some of the tradeoffs we're making when using DDD on a system that it doesn't necessarily suit: Analysis/Design - We map completely skip...