I like DDD. I think the idea that you can express business rules in software in the same terms you use to speak to your customers about their business is wonderful. It seems like a really natural place to go with object oriented design. Eric Evans and Jimmy Nilsson have helped a lot with their books on the subjects. But it can be really confusing for a newbie, especially one like me who wants to see concrete examples of how others have answered questions about how to express these business rules in the best way.
There was a discussion recently on the Domain Driven Design YahooGroup mailing list between Joe Reddy and Frans Bouma that I think encapsultes the issue:
> The developers at my office and I read Evans' DDD book and everyone liked the
> concepts. However we often disagree on implementation. Even within the same
> office we have different pressures, different environments and different
> priorities. These things rarely if ever change our thoughts on the DDD
> concepts; however they always change our thoughts on implementation.what the
> code looks like.
> So when people ask for code to show them how DDD is implemented I am also wary
> of supplying this to them.
> For example, my current team is developing in C# and we have no third party
> O/R mapping tool like I hear often discussed. Any code example with an> implementation of N/Hibernate means little to me.
> With that being said, we are all geeks and sometimes reading code can help
> lead us to some "Ah ha!" moments.
I think some fundamental problems are often ignored and people runinto them sooner or later.
Take for example Microsoft's example database called Northwind. In theentity model, there is obviously a problem, when you want to create aggregate roots and repositories:
Order references Customer
Order references Employee
OrderDetail references Order
OrderDetail references Product
Product references Supplier
Which aggregate roots and which repositories are the best for this situation? before people step in and say: this or that, be aware that there's no real parent/child situation here, except perhaps 'orderdetails' inside order, however orderdetails refers to product, which means the product thus also becomes part of the order aggregate, UNLESS you want to refer to orderdetails from TWO different aggregates (order and product), which can be cumbersome.
If you take a step back and think about this for a while you IMHO will come to the conclusion that the introduction of aggregates and repositories brought this problem onto the table, i.o.w.: it's a side effect of using these abstractions. However, without a proper set of rules-of-thumb, what should theaverage DDD user do to solve these problems? I think THAT's what the people who are asking for examples are after: to see how in real-life situations these things are solved, so they can apply the same solution to their own situation as well.