Layered monolith §
Contact me for information about consulting and training at your company.
Until June 25th, enroll for $95 in my virtual bootcamp, distributed data patterns in a microservice architecture
Context §
Teams own one or more subdomains/bounded contexts.
subdomains/bounded contexts consists of different types of logic:
web
- e.g. REST controllersdomain
- business logicpersistence
- data access logic.
Forces §
- Simple components
- Team autonomy
- Fast deployment pipeline
- Support multiple technology stacks
- Segregate by characteristics
- Minimize design-time coupling
- Maximize cohesion
Problem §
How to structure the monolith/component? How to organize the subdomains/bounded contexts to form a monolith/component?
Domain view: comprised of packages, package hierarchy (and classes)
Component view: comprised of Maven/Gradle modules
Solution §
Structure the monolith/component as a collection of technically-oriented layers, e.g. web
, domain
, and persistence
.
Domain - Packages: com.<company>.<application>.<layer>.<domain>
Component - Maven/Gradle module: web
, domain
, persistence
- I suppose a layer could consist of multiple Maven/Gradle modules.
Implementation of a subdomain/bounded context is spread across the layers.
JPA - what’s the actual layers:
interface CustomerRepository extends JpaRepository<Customer, Long> {}
This can’t be in a persistence
layer, because that creates a circular dependency.
Could have DAOs and DTOs in the persistence layer
Domain layer API:
- Old school - DTOs
- New school - Open Session in View
Variation §
Technically-oriented hexagonal architecture.
Domain - Packages: com.<company>.<application>.<adapter-X|domain>
Component - Maven/Gradle module: adapter-X
, domain
Resulting context §
- Simple, familiar
- JPA entities can reference each other
Benefits §
Drawbacks §
- Simple components
- Team autonomy
- Fast deployment pipeline
- Support multiple technology stacks
- Segregate by characteristics
- Minimize design-time coupling
- Maximize cohesion