Practical Introduction to Domain-Driven Design

Hello, Jarosław! Many thanks for your feedback! I appreciate you taking the time to look over everything and pick up something to tackle.

I believe both of your conclusions stem from the fact that I attempted to make this article shorter - even today, I consider it to be very lengthy. As a result, certain ideas may not be described as thoroughly as I would want.

I definitely intended to illustrate a domain service here; the fact that it is used so "directly" in the final example may be a little deceptive, but I believed that building any extra presentation layer would add unneeded complexity. I also agree that an application service serves as an orchestrator for multiple domain processes, including some external calls. But, given the domain service deals with aggregates and other entities, I believe it should use a repository and dispatch domain events.

In terms of the aggregate, the major point I wanted to make is that the 'Customer' is actually a 'Person' (due to the O2O relationship) who stores the orders. To avoid overcomplicating the example, the only invariant that this aggregate regulates is the total value of all orders. With the aggregate in place, the most crucial feature I wanted to demonstrate is how the full aggregate is committed at once in the repository - as you indicated, to maintain consistency. If you think that's not enough about the aggregate, then you might be right - won't argue about that 🙂

Perhaps if I went into more detail on a few subjects, some of them might appear better. Nonetheless, in general, I'm still really glad if a reader read the post, decided "it's not enough," and reached out for one of the sources recommended.

In any case, huuuge thanks for the excellent points! The articles on your blog that mention books I've read in the past, like "Atomic Habits" or "Deep Work," are looking really interesting. I'll certainly give it a look sometime!