DDD

Feature Name	Description
What is Domain-Driven Design?	Domain-Driven Design (DDD) is a software design method wherein developers construct models to understand the business requirements of a domain. These models serve as the conceptual foundation for developing software. Developers need to collaborate with domain experts to guarantee that the code is aligned with business rules and client needs.
Bounded Context (BC)	A bounded context (BC) is the space in which a term has a definite and unambiguous meaning. The problem is that the larger the domain, the more difficult it is to find a consistent and unified model. DDD’s solution is to identify BCs so that the domain can be broken down into manageable subdomains.
Context Map	The presence of a BC anticipates the need for communication channels. For instance, if we’re working in an e-commerce domain, the salesperson should check with inventory before selling a product. And once it’s sold, it’s up to shipping to ensure delivery of the product to the correct address. In DDD, these relationships are depicted in the form of a context map. Picture
Domain-Driven Design for microservices	DDD takes place in two phases: In the strategic phase we identify the BCs and map them out in a context map. In the tactical phase we model each BC according to the business rules of the subdomain. Let’s see how each phase plays a role in microservice architecture design.
Strategic phase	During this phase, we invite developers, domain experts, product owners, and business analysts to brainstorm, share knowledge and make an initial plan. In strategic DDD, we take a high-level, top-to-bottom approach to design. We begin by analyzing the domain in order to determine its business rules. From this, we derive a list of BCs.
Types of relationships	Next, we must decide how BCs will communicate. Eric Evans lists seven types of relationships, while other authors list six of them. Regardless of how we count them, at least three (shared kernel, customer/supplier, and conformist) imply tight coupling, which we do not want in a microservice design and can be ignored. That leaves us with four types of relationships: Open Host Service (OHS): the service provider defines an open protocol for others to consume. This is an open-ended relationship, as it is up to the consumers to conform to the protocol. Published Language (PL): this relationship uses a well-known language such as XML, JSON, GraphQL, or any other fit for the domain. This type of relationship can be combined with OHS. Anticorruption Layer (ACL): this is a defensive mechanism for service consumers. The anti-corruption layer is an abstraction and translation wrapping layer implemented in front of a downstream service. When something changes upstream, the consumer service only needs to update the ACL. Separate ways: this happens when integration between two services is found, upon further analysis, to be of little value. This is the opposite of a relationship — it means that the BCs have no connection and do not need to interact. At the end of our strategic DDD analysis, we get a context map detailing the BCs and their relationships.
Tactical phase	this stage, which requires developers well-versed in DDD theory, we’ll zoom in on each context to construct a detailed model. The models created with DDD are technology-agnostic — they do not say anything about the stack underneath. We focus, instead, on modeling the subdomain. The main building block of our models are: Entities: entities are objects with an identity that persists over time. Entities must have a unique identifier (for example, the account number for a customer). While entity identifiers may be shared among context boundaries, the entities themselves don’t need to be identical across every BC. Each context is allowed to have a private version of a given entity. Value objects: value objects are immutable values without identity. They represent the primitives of your model, such as dates, times, coordinates, or currencies. Aggregates: aggregates create relationships between entities and value objects. They represent a group of objects that can be treated as a single unit and are always in a consistent state. For example, customers place orders and own books, so the entities customer, order, and book can be treated as an aggregate. Aggregates must always be referenced by a main entity, called the root entity. Domain services: these are stateless services that implement a piece of business logic or functionality. A domain service can span multiple entities. Domain events: essential for microservice design, domain events notify other services when something happens. For instance, when a customer buys a book, a payment is rejected, or that a user has logged in. Microservices can simultaneously produce and consume events from the network. Repositories: repositories are persistent containers for aggregates, typically taking the form of a database. Factories: factories are responsible for creating new aggregates.
Domain-Driven Design is iterative	On paper, bounded contexts and context maps may appear OK, but when implemented, they may translate into services that are too big to be rightly called microservices. Conversely, chatty microservices with overlapping responsibilities may need to be merged into one. Other methods such as Test-Driven Development (TDD) or Behavior-Driven Development (BDD) may be enough for smaller, simpler systems. TDD is the fastest to start with and works best when working on single microservices or even with applications consisting of only a few services.