Domain Driven Design - Parent processing children

Question

Hello, I'm trying to get a handle on good DDD principles, so pardon this question if it is noobish.

Take an Author object that has a Books collection. I want an IsAwardWinningAuthor property on my Author, with each book having an IsAwardWinningBook property. Would I simply make IsAwardWinningAuthor loop through (or query, or whatever) the Books collection looking for any instance where IsAwardWinningBook is true? Is this the proper place for this logic, even if it may trigger a lazy load of all books from my database?

Thanks!

Answer 1

Question isn't about domain driven design at all. It's about technology.

From domain driven design perspective - it matters that You reflect domain correctly (in this case - Author is award winning when any book has won an award). In Your model database related performance problems does not exist.

Unfortunately - we cannot ignore them.

But it's a bit hard to help You. You didn't specify technology You are using. From mentioning lazy loading i guess You are using ORM. Then again - I got no ideas which one.

I've worked with NHibernate and it was smart enough to filter books by author id foreign key on lazy loading book collection. Therefore - it didn't cause selecting all books but just ones i needed.

Another common problem when using ORM You might not be aware of is so called select n+1 problem.

---

About ddd...

Don't stop and don't just assume that You understand it. It's a damn hard nut to crack.

Answer 2

I use an ORM (NHibernate) heavily in my current project and I am starting to lean heavily towards just recording a piece of information if it's important. In your case I would just record on the Author that they are an award winning author. If I needed to find the book I could write a special query to find all their award winning books. It's much more efficient to do so then to load up all the books just to find a simple fact out.

Answer 3

Don't try to solve potential performance issues too early in the process (but don't ignore them, either).

As always, how you actually execute the query depends on the nature of the data, and how it will be used. If you've got a batch process running through tens/thousands of records, you'd want to let SQL Server take care of it.

However, if you only need to execute the query once or twice, with fewer records, you can get away with an in-memory loop.

The missing piece to you solution is this: Use a Query Specification to wrap your query, and make your Author object use this new Query Specification.

Initially, just make it a simple loop. When you discover that it's too slow, replace the loop with a call to the database (via a FindAwardWinningBookCount method on your AuthorRepository).

The important part is this: Your Author object is no longer responsible for handling the query - it uses the Query Specification instead. Changing the Query Specification's implementation should not affect the behaviour of your Author.

See pages 229 to 234 in Evan's book for more detail.

Answer 4

I would model this so that Author has information whether she/he is AwardWinning. When books becomes AwardWinning, it notifies its author (by calling OnBookBecameAwardWinning method) that it became award winning. This method can be as simple as setting AwardWinning flag on the author, or much more complicated. It depends on particular case.