Domain Driven Design (DDD)

• - Centralized BS logic : core idea of DDD focus on Business domain itself, this ensure that software main purpose is solving business problems.
• - Learn, discuss, bring BS value : continuous communication between them, developers and BS people help to each other to understand logic well, and achieve better design, where minimize gaps. Everyone use same language (UL) when discussing in system.
• - Design is code, code is design : there is no strict separation between design and code. Design should be reflected in code, and code need represent the business design.
• -Separation of Concerns : DDD encourage seperating Domain logic from Application/Infrastructure/UI logic. Often implemented with Clean Architecture or Onion Architecture. Note that, Clean and Onion architecture is a software architecture pattern , while DDD is a design and modeling approach.
• - Strategic/Tactical designs: in DDD it brings both, Strategic and Tactical designs together.

1. Strategic design

• ~ Subdomain is a business concept, we use it in Problem space. Simply, we can say it's a spesific part of business domain. Let’s say we are building an online bookstore that are selling books online, this is a whole business domain, but this domain has many parts which are callled subdomains, such as Catalog,Ordering,Billing,UserManagment etc. Each Subdomain is implemented by one or more Bounded Contexts, such as Catalog with CatalogBoundedContext, Ordering with OrderManagementBoundedContext etc. There are 3 types of domain:
  • a. Core Subdomain: is most important, unique part of business. Require deep collaboration with domain experts.
  • b. Supporting Subdomain: is not unique, used to reuse patterns or tools if possible. Eg; User managment.
  • c. Generic Subdomain: is commonly used logic that every company needs. We don't build it unless necessary. Instead using existing frameworks/libraries etc. Eg; Authentication & Authorization, Logging, Payment gateways etc.


• ~ Ubiquitous Language(UL) is a shared language used by both the development team and business people to ensure clear communication. It is created by developers, domain expers and business experts. s. The goal is to define key terms that everyone agrees on and to visually represent domain elements and their relationships using diagrams or models. Terms like “Book,” “Order,” “Customer,” “Discount” are defined and used between business and developers. The UL is only valid on inside a given BC. Each BC has its own UL, and this language can't use across in other contexts, this ensure that language remains clear for given context.


• ~ Bounded Context (BC) is a solution space where we can define and apply domain models 峰 independently. It isolates part of system to solve a specific part of larger problem. In practice, a BC often used with Microservices architecture, where each microservices has its own isolated context, responsibility, and often its own DB and architecture style. As earlier I mentioned, the UL is only valid with its BC, each BC has its own UL, even if multiple BC use similar terminology — like an "Account" in the Billing Context and in the UserManagement Context — the meaning of the term may be completely different within each other. Tactical pattern are implemented in BC. And each BC handle its own solution. BC related to Solution space not Problem space.


• ~ Context Map (CM) provide high level overview to indicate how different BC are related to each other. This is crucial when mapping out integration relationships between multiple BC. There are some relationships between different part of system, ensuring they can work together without conflict, like "Partnership"- two BC are dependent on each other and must either success or fail together


• ~ Shared Kernel is set of common domain models (enties, value objects, servcies) that are shared between two or more BC. It allows context to share some core business logic without completely merging their domains. Eg: in E-commerce app, two teams are working on two Bounded Context: OrderManagment and CustomerService, but both context need to use Customer data (Customer entity, Address value object), instead of each team defining their own version of Customer, they share same domain model of Customer and Address. So this part is Shared Kernel. Since multiple context depend on Shared Kernel, changes to it require careful coordination between teams to avoid breaking other parts of the system.

2. Tactical design

• ~ Entity: identified by unique ID...

Solution Space vs Problem Space