The chapter about DDD is superficial, presents a limited perspective

[jsynowiec]

I wanted to offer some feedback regarding the chapter on Domain-Driven Design (DDD).

The section comes across as somewhat superficial and could be misinterpreted as advocating against the use of DDD altogether. This might unintentionally discourage readers from exploring its benefits. Both strategic and tactical tools from DDD have their place and can be incredibly valuable when applied appropriately (and not necessarily together!). For example, strategic DDD concepts like Bounded Contexts help teams establish clear boundaries in complex systems, while tactical patterns like Aggregates or Value Objects address specific implementation challenges. Strategic DDD is often used alongside other tools like Wardley mapping and the Team Topologies approach to reduce the cognitive load. As usual, it depends on the context and application.

It might be helpful to expand this section to clarify when and where DDD is most applicable, highlighting its strengths without implying it is universally required. Providing examples of contexts where DDD tools can make a significant impact, as well as scenarios where simpler approaches might suffice, could also help the audience better understand its nuanced applicability.

Nevertheless, I agree that "writing code in DDD" misses the point, but it is in itself an indicator of a different problem—limited experience, lack of understanding, and superficial knowledge of those implementing such an approach. It is typically rooted in various "DDD explained in 5 minutes" videos and posts.

Thanks again for sharing your thoughts—I hope this feedback is helpful in refining the chapter!

[zakirullin]

Hi there! Thanks for your thoughts.

Indeed, the section about DDD seems to be superficial. I'd be more than happy to collaborate on refining!

I absolutely love Team Topologies, and the framework that they give. Indeed it can help reducing cognitive load at the team level. But when it comes to DDD, both strategic and tactical, I can see a lot of ambiguity here and there. What I and other observed is that the body of knowledge is so vast and fuzzy, that it becomes not a common denominator, but rather a battleground for debates. So many terms have been introduced, so much taxonomy. Even the same person re-reading Evans comes to a different understanding.

[zakirullin]

@jsynowiec While it is not what you expected, you sparked some thoughts and I decided to add a better conclusion to the chapter.

61c681e

Feedback is very welcome!

[jsynowiec]

DDD, on the other hand, seems to be creating 10 different mental models for 10 different readers. Instead of being common ground, it becomes a battleground for unnecessary debates.

This sentence appears to further reinforce the anti-DDD sentiment. It presents a personal preference and opinion without providing much explanation or examples.

The article would be more comprehensive if this section were revised to explain the opinion rather than simply stating it. As previously mentioned, tools such as bounded context and context maps are visual aids that significantly reduce cognitive load at the strategic level. They allow for direct reference rather than the need to comprehend multiple scattered resources. Simultaneously, a single source of truth and understanding for language reduces cognitive load both laterally and vertically by eliminating multiple interpretations and meanings.

I am confused about you stating that there are multiple terms or definitions of these terms, or that they are subject to free interpretation. Could you kindly provide some examples? How do you debate what the Ubiquitous Language is?

[zakirullin]

@jsynowiec Strategic DDD is somewhat OK. I was mainly talking about tactical DDD, which I often see people apply.

The article would be more comprehensive if this section were revised to explain the opinion rather than simply stating it. As previously mentioned, tools such as bounded context and context maps are visual aids that significantly reduce cognitive load at the strategic level. They allow for direct reference rather than the need to comprehend multiple scattered resources.

What you say is reflected here:

Ubiquitous language, domain, bounded context, aggregate, event storming are all about problem space. They are meant to help us learn the insights about the domain and extract the boundaries. DDD enables developers, domain experts and business people to communicate effectively using a single, unified language.

The article also advocates for single source of truth. Is it a part of DDD as well? :)

I am confused about you stating that there are multiple terms or definitions of these terms, or that they are subject to free interpretation.

There are plenty of them. You sure saw some discussions like these once you apply DDD:
https://stackoverflow.com/questions/18625576/confused-about-bounded-contexts-and-subdomains
https://stackoverflow.com/questions/32353835/difference-between-an-entity-and-an-aggregate-in-domain-driven-design
https://www.reddit.com/r/DomainDrivenDesign/comments/17e48wb/conflicting_info_subdomain_and_bounded_context/

Often times different books on DDD conflict each other.

My main point is that developers say "we apply DDD", when in fact they used a bunch of things from tactical DDD. Or they try to apply somewhat generic principles from strategic DDD straight to the code. While in reality what is worth doing is modeling, understanding both the business and system as whole.

For example, things like these can be of tremendous help. Find what's core for our business, what is our competitive advantage, what is important for the business to make money, what we probably should build in house. Find what is not so important, what can be outsourced, etc.

That's good stuff! In reality it comes down to developers discussing how to reflect that, or other, part of DDD in the code. Codebases where people applied DDD were verbose and abstract, one of the hardest to understand. And I've never seen complimentary artifacts where some modeling or any strategic DDD procedures were conducted.

If you have examples where "proper DDD" was implemented, please share.