Making it more complete?

[plalx]

Interesting modeling exercise!

If you want to enhance it and keep fooling around you could also implement Bounded Contexts, which is probably the most important modeling pattern.

The current domain problem space is not complex enough to make use of Bounded Contexts, but I believe it would if you added features for creating new house plans and pre-defined visit paths.

You could have the HouseManagement and the Visitor contexts, or something like that...

Also, I believe that the House concept is doing too much in the current implementation; the design would benefit from a Visit concept that would track the state of the visit rather than putting that responsibility on the House.

Have fun!

[jenkoian]

Hi, thanks for the feedback!

Yeah, I started off with a vague idea of some contexts, similar to the ones you mentioned. So HomeOwner was the initial context, and then I had planned to do like a visitor context, or potential buyer I think I called it initially (was thinking it could be some kind of home selling tool).

I should really pick this back up and make more complete.

I am interested in what you said about the House concept too, I've found (in other examples as well as this) that my Aggregate Root often ends up doing too much, but it kinda matches the UL. In this instance, you enter a room of a house...in another example I've messed around with, you check out a book from the library..etc. Any tips around this?

[plalx]

Sometimes the problem might be that your ubiquitous language is not expressive enough. Refining the ubiquitous language is an ongoing process as your learn more about the domain. Furthermore, never forget that the code is the true model and that's often while crafting your aggregate boundaries that you discover important business concepts. It's not only up to the business experts to craft the UL, it's a collaboration between the business experts and the developers.

Also, remember that you do not try to model the reality, you only model what's needed to effectively cover the business use cases.

For instance, in a book loaning application, you wouldn't have a Library aggregate that has a collection of Book entities even though in reality book are in libraries. Having a large cluster Library aggregate would be truly impractical. There's no business use case that requires all books to be part of the same consistency boundary. The library concept itself doesn't seem very important and probably wouldn't have to be modeled at all. I guess you could always name the BookRepository a Library however.

[jenkoian]

Thanks @plalx that makes a lot of sense yes, I just read the http://dddcommunity.org/library/vernon_2011/ series of articles also and things are a little clearer now.

I think in my case of the library I should probably the 'library' as a domain service or similar which does the actual checking out of books etc. similar to the ProductBacklogItemService example in http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf

[plalx]

These are excellent articles, I've read them a few times already. Crafting aggregates efficiently is definitely not an easy task and requires a lot of practice.

You may want a domain service if a lot of business logic would be leaking into the application service, but make sure you need one first or you might just as well end up with an anemic domain model.

Also, a LibraryApplicationService could potentially make sense, but at the same time it may push you towards modeling too many operations under that concept, since you might see most operations as being related to a library which is in essence the application you might be building.

For instance, with a statement like "becoming a member of the online library" you may be tempted to add membership management behaviors within the LibraryApplicationService and before you realize it this service will become a god object that could be very well renamed ApplicationService.

That's one reason that make me think that it may be better to name services after the aggregates they are related to e.g. BookApplicationService and that's what I've seen in most examples.