A DDD style

I agree with Brendan Tompkins that Steve Maine wrote a very interesting blog post here. I'm looking forward to the next part!

The result Steve comes up with is pretty different from my own current favorite style. Not that that means mine is better, but I thought it might be interesting to say a few words in comment to Steveís article. The major differences are:
  • I don't want my Entities to talk directly to the Repositories themselves. The way I see it, only external consumer classes (in the Application layer in Eric Evans lingua franca) should talk to the Repositories.

  • I use a specific interface for each Repository. I guess I would be more inclined to try a generic interface approach when I have generics in place, but it might still be problematic. The main purpose of my interfaces is to make it easy to start with a stubbed version of each repository for TDD purposes.

  • I think of the infrastructure as something that is external to the Repositories. Sure, the Repositories communicate with the chosen infrastructure, for instance when executing queries and preparing to persist an entity, but the actual work itself is done by the infrastructure. I guess this is a bit cryptic, but it gets clearer when you consider saving. Then I let the infrastructure provide a Unit of Work (combined with an Identity Map) that is shared between several Repositories (given to the Repositories at instantiation time). When it's time to persist all changes registered to the Unit of Work, the consumer tells the Unit of Work directly to take care of it.

  • I don't use nested classes for the Repositories, probably because I first write a stubbed Repository for TDD purposes and it would feel strange to have two Repositories nested within each Entity.
Why is my current style so different? Again, I'm not sure it's better, but it's different, at least.
Perhaps this might explain it:
  • As I said, I want an external Unit of Work to control the complete object graph that the Repositories act upon. This makes it easy to store changes to both the Customer and the Address from Steve's example within the same physical database transaction.

  • I started out thinking about the style with an OR Mapper in mind for the infrastructure. Sure, I could also write the whole persistence thing for my style with custom code, but it becomes messier.
I haven't really tackled the problem Steve was trying to address here, i.e. having two Aggregates with one of them being a composition of the other one, and I would probably try to design away from the problem. However, if itís just not possible (OK, perhaps "suitable" is a better word), then I would go for infrastructure supported Lazy Load or let the load be dealt with from the external consumer. Neither feels optimal, but both work.

Again, I'm looking forward to Steve's next article on this topic! Your take?