A deployment unit is a system component that can be tested and deployed to production independently. It creates a deployment boundary around software that may change together. section 3.3
Deployment units differ from bounded contexts: bounded contexts define linguistic boundaries, while deployment units define release boundaries. They may align, but they do not need a one-to-one relationship. section 3.3.3
Use these relationships when shaping an architecture:
- Align a bounded context with one deployment unit when its size and dependencies make that practical. section 3.3.3
- Avoid splitting one bounded context across multiple deployment units when its logic is likely to change together. section 3.3.3
- Place multiple bounded contexts in one deployment unit when a modular monolith is appropriate, without making the unit too large. section 3.3.3
- Apply the heuristic: what changes together gets deployed together. section 3.3.3
BigScreen architecture
A redesigned BigScreen architecture aligns Price Calculation, Payments, and Seat Allocations one-to-one with deployment units. User Interface and Ticketing share one unit, while PaS and Movie Scheduling remain separate units within one domain. section 3.3.3
Figure 3.10 New architecture for BigScreen, designed via collaborative modeling. This architecture captures the complexity of the domain with multiple bounded contexts and deployable units. Price Calculation, Payments, and Seat Allocations bounded contexts align one-to-one with a deployable unit. User Interface and Ticketing are two bounded contexts in one deployable unit. PaS and Movie Scheduling are a single domain but are in two deployable units. This architecture makes the “Anytime, Anywhere” campaign possible.
Compare the alternative BigScreen arrangements and see how collaborative modeling connects domain complexity, bounded contexts, and deployment units. section 3.3.3
