Big ball of mud

As the systmem grows, the code can get unnecessarily complex and messy which is hard to maintain. Strategic design provides a set of principles and techniques to define ubiquitous language, maintain integrity of the model and reduce the complexities by splitting the models into small, independent models with clear boundaries.

Problem space ➡ Solution space

Business domain is where we are going to focus to solve in DDD. This is called problem space. Business domain is often too big so we usually focues on a subdomain, a logical area in the domain where a specific problem is located. There are three types of subdomains.

• Core

  • a business area that can be distinguished from the competitors
  • a stratetic investment area that has a high priority
  • Where the most values lie

• Supporting

  • an area where the custom development is required
  • it is important for successful core subdomains

• Generic

  • it is not specialised but required for the overall business solution

Bounded context

A bounded context is an independent, logical boundary where the ubiquitous language is explicit and consistent. In the boundary, each component in the model has a specific meaning and does a specific thing. For example, 'Customer' in the picture below has different meaning in each domain.

Ideally, a subdomain in the problem space needs to be aligned with a bounded context in the solution space but it is not always a one-to-one mapping. A bounded context may be mapped to several subdomains in some legacy systems.

Context Map

A context map describes the relationships between the contexts. There are different patterns you can identify in the context map.

Patterns

• Separated ways

  • No dependency
  • There may be some duplicates but each context exists independently

• Shared kernels

  • Multiple bounded contexts share the same module
  • It is an anti-pattern

• Partnership

  • Two contexts are grouped into one transaction
  • Two phase commit?

• Customer-Supplier

  • Supplier provides the corresponding information to the customer
  • Upstream = Supplier, Server
  • Downstream = Customer, Client
  • One way dependency

• Conformist

  • Customer (Downstream) conforms to the supplier (Upstream)

• Anticorruption layer

  • Downstream builds a layer between downstream and upstream. The layer converts the data that downstream can understand
  • Usually downstream context has ACL

• Open host service

  • When there are many external systems to be integrated, an open host service can provide the protocols that other contexts can utilise.
  • REST API, RPC, Socket

• Published language

  • One way communication
  • Json, XML, byte

Event storming

It is a brainstorming like method to find all events happening in the domain and identify bounded contexts.

Define domain events

An event is a result from an actor's action. The event should be in past tense. Just write down whatever comes up in your mind and then remove or combine the duplicates. You need to put the events in a sequence. If the events occurs at the same time, put them in paralell. I used orange color to identify domain events here.

This involves storytelling. You need to discuss in the team and understand the workflow in the domain.

Group the process

You can find some events can be grouped together as the same work process. Unlike core business processes, you don't need to describe the supporting process in depth.

Define commands

A command is an action that triggers an event. It is written in the present tense. Usually, it matches to CRUD action.

Define triggers

Now it's time to dig deeper to figure out whom (actor, external systems) and how (rule, policy). The external systems can trigger an event without a command. Therefore, unlike an actor, you don't need to put a command next to it. The rules/policies can be infomration that is required to trigger an event or at the execution of the event. The rules/policies can also trigger an event. ex) timer

Define aggregates

You need to fine a data object that is required to execute a command. For example, a shipping address can be included in a recipient info.

Identify bounded contexts

Now you can group the elements by a unique business purpose. After identifying the bounded contexts, you can draw a context map to show the relationships between them.