Book Review: Learning Domain-Driven Design part. 1

Domain-driven design's core philosophy is simple: our applications should be modeled based on business needs. Sounds obvious, right? So why are there countless books, podcasts, and conferences dedicated to this topic? Would those patterns help me to design better software? This question followed me throughout my career, surfacing during discovery sessions with stakeholders and discussions with peers. I knew I needed to investigate further.

During my research, I encountered a banana-gorilla problem. The seemingly straightforward concept of DDD came bundled with cryptic terms—bounded contexts, hexagonal architecture, event storming, CQRS—raising more questions than answers.

• Is all this complexity necessary to benefit from DDD?
• Can DDD be applied to front-end software design?
• Am I heading down a path of over-engineering?

While seeking clarity, I discovered Learning Domain-Driven Design by Vlad Khononov, published by O'Reilly. The reviews praised its accessible and pragmatic approach. I gave it a try, and it lived up to the praise. If my experience resonates with you, I strongly recommend this book.

In this three-part series, I'll explore the book's chapters, sharing their content along with personal thoughts and resources that helped me better understand these concepts.

Part 1: Strategic design

The first part of the book contains no architecture diagrams or code snippets. Instead, it focuses on business analysis, competitive advantages, and business language. This sounds scary, but stay with me!

The DDD process, as its name suggests, begins with the problem's domain—the business environment our software will operate in.

Analyzing business domains

The first chapter explains how to break down a business's broad scope into smaller subdomains. Each subdomain's type is determined by the competitive advantage it offers:

• Core subdomains are the distinctive features that make a business stand out and give it a competitive edge. These features must be developed in-house and require careful attention.
• Generic subdomains, as stated by the author, are the "known unknowns"—complex but common features like authentication or CMS. For these, it's usually better to choose existing solutions rather than build them from scratch.
• Supporting subdomains are too business-specific to be generic but don't provide a key advantage. They're simply necessary for business operations, like a custom admin dashboard.

This analysis helps prevent common pitfalls:

• Reinventing the wheel (by coding a generic solution ourselves)
• Neglecting a core subdomain
• Over-engineering supporting solutions, thus wasting time we should spend on competitive subdomains

Real-life examples and schemas make the concepts clear and relatable through the chapter.

Discovering domain knowledge

The second chapter introduces ubiquitous language, a key concept of DDD:

Every participant in the project should use the same terminology for the same concepts.

“Duh, and we are where we are” you might think. It sounds like a common-sense platitude, but can’t you recall times in your work life where naming the same concepts differently caused miscommunication issues, leading to waste, poor implementation or bugs? I sure can do. From my experience, this is especially true in discussions that involve technical jargon, which can lead to big misunderstandings.

By establishing that "ubiquitous language is the language of the business," we foster effective communication between domain experts, product teams, and engineers. The author discusses this as a continuous process, recommending tools and frameworks to strengthen it. Most importantly, this chapter emphasizes the need for streamlined interactions between participants. As the Agile Manifesto states:

Individuals and interactions over processes and tools

Managing domain complexity

While we've seen that subdomains are discovered through business analysis, modeling our system's architecture requires a different approach to organizing use cases. Chapter 3 introduces the notion of bounded contexts.

A bounded context creates a boundary between application contexts, providing a focused scope for each one. This separation offers multiple advantages:

• It provides context for language used within its boundaries. For instance, a "lead" might mean different things to marketing and sales departments. The bounded context ensures consistent meaning within its scope.
• Bounded contexts establish physical (services, repositories) and software (architectures, frameworks) boundaries, enabling clear team ownership and appropriate tool selection.

As stated:

While subdomains are discovered, bounded contexts are designed.

The insights gained from discovering subdomains and establishing ubiquitous language should guide how we design our system's boundaries.

Integrating bounded contexts

Having designed our bounded contexts, the last chapter explores three sets of strategies for communication between them:

• Cooperation, where two contexts share a part of the codebase.
• Customer-supplier, where one bounded context uses another one as a service.
• Separate ways, where there is no collaboration at all.

This chapter offers great insights and practical guidance for each model. It concludes with an introduction to the Context Map—a tool for visualizing the different contexts and their interactions.

In summary, the first part of the book is remarkably clear and packed with real-life examples, advice, and quizzes. It ties together the concepts of domains, ubiquitous language and bounded contexts naturally and explicitly. This gave me a deeper understanding of the fundamentals and core principles of the DDD philosophy.

The book begins with very abstract concepts like business domains and gradually builds up to contexts modeling, defining applications separation and practical strategies.

This reading resonated strongly with my experience as a developer, providing valuable tools for discovering business domains and translate them to actionnable insights. While DDD can be hard to bring in as it requires an organizational buy-in, Learning DDD provides practical insights that can enhance your discovery and design sessions, even without fully embracing the methodology.

In the next article, we'll explore the second part, diving into implementation with software architectures and coding patterns—this time with diagrams and code examples, I promise! See you there.