Domain-Driven Design - Part 1 - Strategic Design

Introduction

Domain-Driven Design (DDD) is a well known concept of software design approach based on domain models explaining in the book Domain-Driven Design: Tackling Complexity in the Heart of Software in 2003 by Eric Evans and Implementing Domain-Driven Design in 2013 by Vaughn Vernon.
We are starting with the "theorical part" of the DDD concept, the Strategic Design.

Type of Subdomains

In DDD, a Business domain (the main area of focus for a company) typically comprises three types of subdomains:

1. Core subdomains - Specific/unique from other company
   These are specific and unique to a company, often involving new technologies or services that differentiate it from competitors. For example, AWS's core subdomains include e-commerce, cloud computing, and artificial intelligence.

2. Generic subdomains - Performing in the same way as other company
   These are areas where using existing solutions (off-the-shelf software) saves time compared to developing custom solutions. Examples include AWS IAM (Identity and Access Management) and online retail platforms.

3. Supporting subdomains - It does not provide any competitive impact
   These subdomains do not directly impact competitiveness but support the overall business domain. Examples include CRUD operations (Create, Read, Update, Delete) and ETL (Extract, Transform, Load) processes.

Ubiquitous Language

Communication between business stakeholders and developers can be challenging due to differing perspectives.
DDD introduces an Ubiquitous Language to facilitate efficient communication and active participation of domain experts.
This language can be documented using various methods such as wikis or word documents, ensuring clarity and consistency in communication.

Bounded Context

A Bounded Context divides the ubiquitous language into smaller, explicit contexts. For example, in a business model, contexts could include "shopping" and "accounting."
While these contexts can evolve independently, they must integrate with each other, often through contracts.

Patterns of Integration

Cooperation

• Partnership : The integration between bounded contexts is coordinated in an ad hoc manner. The communication is two-way, teams cooperate during the work. Often, this process involves a collaboration between two software companies, or a software company and a hardware company, to integrate their respective products or services, thereby improving the experience for the end user.

• Shared Kernel : This integration is used when two or more bounded contexts have to communicate with each other via a shared model (e.g: Shared JARs or Database schema). Each context can modify the share model and take effect on other bounded contexts.

Customer-Supplier

It is a upstream-downstream relationship where the supplier is the upstream and the customer the downstream.

• Conformist : The client (downstream) has to be conform from what the supplier (upstream) sent to it. There is not translation of models.

• Anticorruption layer It is the other side of conformist, the client (downstream) translates the data (bounded context's model) into a model tailored to it is own context/domain. The ACL acts as a translation layer, ensuring that the two systems can communicate without corrupting each other's design and functionality. The legacy system uses an old relational database model and communicates via SOAP web services, while your system uses a modern RESTful API architecture.

• Open Host Service The supplier (upstream) is intended to expose a protocol convenient (translate the data before send the message) using a public language for the consumers (downstream). We can use web services or micro-services defined services using a API for your service to expose an interface openly accessible.

Separate Ways

Integration between contexts does not involve collaboration between teams.

Go further

The connections between the bounded contexts can be visualized on a context map. This tool provides understanding of the system's overarching structure, communication flow, and potential organizational challenges.

Now that you've gained insight into techniques of domain-driven design for examining and modeling business domains, we'll pivot our focus from strategic considerations to tactical approaches that you can find here.

Thank for reading

If you have any questions, feedback, or suggestions, please feel free to leave them in the comments below. I'm eager to hear from you and respond to your thoughts!