DDD Step By Step
A Practical Guide to Domain Driven Design
DDD on the Web » All Tags » Domain-Driven Design (RSS)

Browse by Tags

Sorry, but there are no more tags available to filter with.

  • DDD Aggregate Component pattern in action by Jimmy Bogard

    In my last post, I went on a long-winded rant on how the composition and the Aggregate Component pattern can ease the burden of the interaction between Entities and Services.  The question comes up often on DDD or IoC forums: How do I inject/use a Service/Repository inside an Entity? You can get really fancy with your ORM or really fancy with your IoC Container to try and make your Entities join in an unholy matrimony.  But there are other, better ways of skinning this OO cat. The hard way We may try to get these services injected through our ORM or IoC container, or we could try and do a static, opaque or service located dependency directly inside our entity: public class Order { public decimal CalculateTotal() { decimal itemTotal = GetSubTotal(); decimal taxTotal = TaxService .CalculateTax( this ); decimal discount = DiscountCalculator .FindDiscount( this ); return itemTotal + taxTotal - discount; } In this snippet, we have an Order entity that is apparently responsible for calculating up-to-date tax and discount information.  We’ll get back to that cluster in a second.  First order of business, how do we deal with these two dependencies, the TaxService and DiscountCalculator?  A few options include: Static...

  • Crafting wicked domain models with Components in DDD by Jimmy Bogard

    Domain-Driven Design can help focus development efforts into crafting a strong, expressive domain model.  In Evans’ book, he dives in to a series of patterns which, when combined, form that strong domain model.  These patterns include Entity, Value Object, Service, Factory, Repository, Aggregates and Roots.  I think one of the biggest mistakes of someone learning and applying DDD is assuming that our entire model needs to fit into those few definitions. When you do so, you wind up in spots where you’re trying to use a Repository from inside an Entity, or violating other more basic OO design principles.  When you’re feeling like you’re bending over backwards to fit everything into one paradigm, it’s time to stop, take a step back, and try a different angle.  The GoF design patterns book introduced a lot more patterns than described in Evans’ book, and all are valid inside the domain.  We shouldn’t artificially limit ourselves to the patterns in Evans’ book, as it was never meant to be an exhaustive domain patterns library.  Many times, what looks like a DDD problem is just an OO problem hiding in plain sight. One example I’ve seen of a powerful OO design concept not explicitly called out is the Component...