Scrumban Product Management

How to Embrace Adaptive Domain-Driven Design

Tips on challenging dogma, focusing on practicality, and adapting practices for effective software product strategy.

Imagine you are trying to build a large city. To ensure the city functions smoothly, you need a master plan that organizes various districts (business, residential, industrial) and defines how they interact. Similarly, Strategic Design in DDD provides the master plan for organizing different parts of a complex software system.

Domain-Driven Design

Staying flexible and practical is crucial to executing that plan. Effectively applying DDD requires challenging dogma, emphasizing tactical solutions, and adapting practices to fit specific contexts. The following steps can help you navigate the complexities of your products and deliver successful outcomes.

1. Challenge Dogma

Actively question established practices within DDD. Even though a method is widely accepted, there are better fits for your product. Evaluate each principle critically and adapt it to your context. Avoid rigid adherence to rules that don't add value. For example, when reviewing your product's architecture, identify which principles benefit your goals. Consider streamlining certain practices to suit your needs if they seem overly complicated or irrelevant. Your aim is to enhance functionality and efficiency, not to follow dogma for its own sake.

2. Emphasize Practicality

Focus on practical implementation over theoretical perfection. Strive for solutions that work effectively in real-world scenarios. When applying DDD, prioritize approaches that address immediate needs and enhance productivity rather than getting bogged down in complex theoretical constructs. For instance, choose the simplest model that meets your requirements when designing a new feature. Test it in a real-world environment to ensure it works as intended. Practicality often means making compromises, but those compromises should lead to quicker, more effective results.

3. Adapt to Context

Tailor DDD practices to fit the unique requirements of your product and organization. Recognize that different products may necessitate different approaches. Stay flexible and be willing to modify or even discard certain DDD principles if they don't serve your project's goals or context. Adaptation is critical to successful implementation. For example, a startup might need to move quickly and benefit from a more streamlined approach to DDD, focusing on immediate deliverables. In contrast, a large enterprise might require more robust and comprehensive DDD practices to manage its complexity. Assess your situation and adapt your strategy accordingly.

How have you adapted DDD practices in your product design journey? Please share your experiences and insights in the comments to help build our professional community.

Clap if you found this helpful content. Your support helps the Medium algorithm display this article to more product managers, contributing to our collective knowledge and success.

PS: Domain-Driven Design Strategy

One of Eric Evans's book's core sections is the strategic design chapter. This chapter is pivotal as it introduces high-level concepts and methodologies for managing complexity in large systems by focusing on the structure and relationships within the domain.

The Essence

Bounded Context

• A bounded context is a specific responsibility within the domain with clear boundaries. Each bounded context has its own model, consistent within its boundaries, but can differ from models in other contexts.
• This helps manage complexity by breaking down an extensive system into smaller, more manageable parts. It also prevents the so-called "big ball of mud" anti-pattern, in which everything is interconnected in an unmanageable way.

Context Map

• A context map is a visualization that shows how different bounded contexts within a system interact.
• This helps understand and plan the integration points and communication flows between system parts. Ensuring that the overall system architecture remains coherent and maintainable is essential.

Relationships Between Contexts

• Shared Kernel: When two teams share a standard part of the model. This requires close cooperation and frequent integration to ensure consistency.
• Customer-Supplier: One team (supplier) provides a service or data to another team (customer). The supplier is responsible for meeting the customer's requirements.
• Conformist: The team consuming the model must conform to the supplier's model without changes.
• Anti-Corruption Layer: A layer that translates and protects the integrity of one model from the influence of another model when integrating different bounded contexts.

The Action Plan

1. Identify Bounded Contexts
   — Analyze the domain to identify distinct areas of responsibility.
   — Define clear boundaries for each context, ensuring they encapsulate specific functionalities without overlapping.
2. Create Context Maps
   — Visualize the bounded contexts and their relationships.
   —Use the context map to identify potential integration challenges and plan for solutions like the anti-corruption layer.
3. Manage Relationships
   — Establish processes for regular synchronization and conflict resolution for shared kernels.
   — Maintaining clear communication about requirements and expectations in customer-supplier relationships.
   — Ensure your team understands and adheres to the supplier's model for conformist scenarios.
   — Implement anti-corruption layers where necessary to maintain the integrity of your context's model.

Domain-Driven Strategic Design Cheatsheet

Blind Spot

A common misconception is that defining bounded contexts and their relationships is a one-time task. However, as the domain and requirements evolve, so should the boundaries and relationships. Regular reviews and adjustments are necessary to align the architecture with the business goals.

Connected Knowledge

To deepen your understanding of strategic design in DDD, consider exploring the following resources:

• Implementing Domain-Driven Design by Vaughn Vernon: This book builds on Evans' work and provides practical guidance for implementing DDD principles.
• Microservices Architecture: Understanding microservices can complement strategic design by providing insights into decomposing systems into independently deployable services.
• Event-Driven Architecture: This approach can enhance the decoupling of bounded contexts, making systems more resilient and scalable.