Layered monolith

Context

Teams own one or more subdomains/bounded contexts.

subdomains/bounded contexts consists of different types of logic:

• web - e.g. REST controllers
• domain - business logic
• persistence - 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

Issues

Related patterns

Motivating patterns

Alternatives

‘Successor patterns’