Modular monolith

---

Also known as

Domain-oriented component

Context

TODO - shared with Layered monolith

Forces

TODO - shared with Layered monolith

Problem

TODO - shared with Layered monolith

Solution

Structure the monolith/component as a collection of (sub)domain/BC-oriented modules, e.g. customers, orders, and deliveries.

Domain - Packages: com.<company>.<application>.<domain>.<layer>

Component - Maven/Gradle module:

• module per domain - customers, orders, and deliveries.
• multiple-modules per domain - customers-<layer>, orders, and deliveries.

Implementation of a subdomain/bounded context is implemented by a single module.

What is the nature of each module’s API?

• What’s to stop class Order { Customer customer; }?
• Choice:
  • Service-style facade with DTOs
  • Open

Variation

Domain-oriented hexagonal architecture.

Domain - Packages: com.<company>.<application>.<domain>.<adapter-X|domain>

Component - Maven/Gradle module: <domain>-adapter-X, <domain>-domain

Resulting context

Benefits

• Team autonomy

• Fast deployment pipeline
  • Only the (TODO-not exactly transitive) dependencies of the changed module need to be rebuilt/retested
• Minimize design-time coupling
• Maximize cohesion

Drawbacks

• Simple components
• Support multiple technology stacks

• Segregate by characteristics

• class Order { Long customerID; } - more code to explicitly traverse relationships between entities
• Additional code for mapping DTO<->Entity/Value Object
• Build-time coupling: clients rebuild/retests whenever implementation changes

Issues

Related patterns

Motivating patterns

Alternatives

• Layered monolith

‘Successor patterns’

• API Module