Vernon (2016), on 2nd chapter:
Problem Space VS Solution Space
Problem space is where you define project drivers at a very high level. Think of it as Business StrategyTactic VS Strategy. Solution Space is where we apply Strategic Design around Domain-Driven Design (DDD) and its more closely related business tactics (againTactic VS Strategy)
DDD - Bounded Contexts are great tools for the solution space
DDD - Bounded Contexts
The bounded context encompasses the entities that are relevant to that specific DDD - SubdomainsAlthough bounded contexts can contain more than 1 subdomain, it's best practice to limit to 1. So one bounded context contains one subdomain and vice-versa.. Everything that's essential for that context should lie there. Everything else should be in another bounded context.
Each bounded context has its own DDD - Ubiquitous Language. So we have context-specific, but very precise terms.
A todo list app could be broken down into the following bounded contexts:
- The list context: contains lists, tasks in lists, assignee (users in the users context)
- The user context: contains user data
- The account context: contains billing data
The list context here would be our core domain (see DDD - Subdomains) since it'd be the HEART of the business.
Look into DDD - Interaction with external bounded contexts for implementation tactics and read DDD - Context mapping for a better conceptual grasp around those interactions.
DDD - Ubiquitous Language
Ubiquitous Language is all about having unambiguous and precise naming for entities within a DDD - Bounded Contexts. When we think about language in development, we focus on nouns, but it's important that we encompass language as a whole:
- Entities should be mapped to specific nouns
- Actions should consistently use the same verbs
- Variations should use precise adjectives
- etc etc
For instance, in a todo list app:
user can create lists and add tasks to them. Each task can have a single assignee and this assignee should be able to archive, complete or assign this task to another user.
The author suggests DDD - Event Storming as a good way to discover candidates for our vocab.
DDD - Interaction with external bounded contexts
DDD - Bounded Contexts should interact with other bounded contexts via well defined, external APIs. There are several tactics for that:
For communication:
- Event driven architecture (see also DDD - Domain Events)
- Command Query Responsibility Segregation
- Reactive and Actor Model
- Representational State Transfer (REST)
- Remote Procedure Call (RPC)
Possible architectures:
- Service-Oriented Architecture (SOA)
- Microservices
- Monoliths with well defined internal APIs (removing the R from RPC :p)
DDD - Domain Events offer good advice on how to establish clear communication standards and DDD - Event Sourcing offers an idea on how to guarantee recovery.