Introduction

Domain-Driven Design (DDD) helps teams model software around a complex business domain. Domain Storytelling is one collaborative technique for learning how people, processes, and systems interact before committing to a model.

The Prelude: The Need for DDD

A requirements list without the surrounding business rules, language, and constraints can produce a technically correct implementation of the wrong model. DDD addresses that risk through sustained collaboration with domain experts.

Understanding Domain-Driven Design

DDD is not just a set of practices; it’s a philosophy that puts the project’s domain at the heart of every decision. Here’s what it entails:

  • Ubiquitous Language: This is the cornerstone of DDD. It’s about creating a common language that’s shared among all stakeholders, from developers to business analysts. This language is used to describe all aspects of the project, ensuring clear communication and understanding.

  • Model-Driven Design: In DDD, the focus is on creating a robust domain model that accurately represents the business domain. This model guides the design of the software, ensuring that it aligns with the business needs.

  • Bounded Contexts: DDD divides the domain into multiple bounded contexts, each representing a distinct part of the domain with its own model. This helps in managing complexity by isolating different parts of the domain.

  • Context Mapping: Understanding how these bounded contexts interact with each other is crucial. Context mapping helps in identifying and managing these relationships, ensuring that the overall system remains cohesive.

Domain Storytelling

Domain Storytelling captures concrete work scenarios in a visual, shared form. It supports discovery; it does not replace bounded-context design or validation with the people doing the work.

Crafting the Story:

  1. Inclusive Gatherings: Bring together all stakeholders, ensuring everyone’s voice is heard.
  2. Narrative Over Diagrams: Use simple, relatable stories to describe user interactions, avoiding technical complexities.

The Art of Pictographic Language:

  • Simple Elements: Use symbols like actors, work objects, actions, and sequence numbers to depict the story.
  • Guiding Principles: Avoid repeating actors, focus on scenarios, and consider the scope in terms of granularity and digital versus physical interactions.

Applying DDD; The Scenario: Car Purchase Journey

Imagine a scenario where a customer is looking to purchase a car on installments. This process involves several steps and stakeholders, making it an ideal candidate for applying DDD.

Step 1: Understanding the Domain

  • Identify Key Entities: Our domain involves entities like Customer, Car, Salesperson, Finance Agreement, etc.
  • Develop Ubiquitous Language: Establish common terms understood by all stakeholders. For example, “Finance Agreement” is a term everyone understands the same way.

Step 2: Creating the Domain Model

  • Model the Entities and Their Relationships: Map out how these entities interact. For example, a Customer chooses a Car, interacts with a Salesperson, and signs a Finance Agreement.
  • Focus on Business Logic: The domain model should capture the logic and rules of the car purchasing process, such as credit checks, payment plans, etc.

Step 3: Implementing Bounded Contexts

  • Define Contexts: Break down the domain into manageable contexts, like “Sales,” “Finance,” and “Inventory.”
  • Context Interactions: Understand how these contexts interact. For instance, “Sales” may initiate a credit check process in “Finance.”

Step 4: Continuous Collaboration and Refinement

  • Engage Stakeholders: Regularly consult with salespeople, finance officers, and customers to refine the model and understand their needs.
  • Iterate the Model: Continuously refine the model based on feedback and new insights.

Step 5: Translating to Code

  • Implementing Entities and Relationships: Translate the domain model into code, creating classes, and methods that reflect the real-world entities and processes.
  • Building the User Interface: Design the UI to align with the domain model, ensuring it’s intuitive for users, like having a clear flow from car selection to financing.

Step 6: Leveraging Domain Storytelling

  • Narrate the Customer’s Journey: Use Domain Storytelling to depict the customer’s experience, from entering the dealership to driving away with the car.
  • Visualize with Pictographic Language: Create diagrams that represent the steps in the process, such as selecting a car, discussing with a salesperson, and signing documents.

Wrapping Up: Embracing DDD for Better Collaboration

DDD, coupled with Domain Storytelling, is not just a method; it’s a mindset shift. It brings clarity, efficiency, and a user-centric focus to software development. It’s a way to make the development process more enjoyable and inclusive for everyone involved.

Further Exploration

To delve deeper, check out “Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software” and visit domainstorytelling.org.

The companion article covers practical DDD practices and pitfalls.

Use DDD where domain complexity justifies the modeling investment. A simple data-entry application may not need the full strategic and tactical pattern set.