Architecture and Pattern Recipes

These recipes show how to express common source-code boundaries with Deply. They are editable starting points, not built-in presets. Architecture styles can be combined: a modular monolith can use hexagonal boundaries inside each module, while one complex module can use CQRS or event sourcing.

Deply checks static structure and imports. It cannot prove runtime properties such as transactionality, message delivery, idempotency, consistency, retries, deployment isolation, or operational ownership.

Choose by Design Problem

Design problem	Start with
Organize dependencies into conventional tiers	Layered / N-tier
Isolate the application from frameworks and external systems	Hexagonal, Clean, or Onion
Keep one deployable split into business modules	Modular Monolith or DDD / Bounded Contexts
Organize code around features or requests	Package by Feature, Vertical Slice, or Use-case Action
Separate independent services in one repository	Microservices Monorepo
Build an extensible core or processing chain	Microkernel or Pipe-and-Filter
Choose a business-logic organization style	Transaction Script, Service Layer, or Domain Model
Separate reads, writes, events, and projections	CQRS, Event-Driven, or Event Sourcing
Choose a persistence boundary	Active Record, Data Mapper, or Repository + Unit of Work
Structure server-side presentation	MVC / MVT

Core Architecture Styles

Decomposition Styles

Application Logic Styles

Data and Messaging Styles

Presentation Styles

MVC / MVT

Common Workflow

For every recipe:

Adapt directories and package names to the project.
Validate the configuration.
Run analysis and review violations before changing rules or code.

deply validate --config=deply.yaml
deply analyze --parallel --config=deply.yaml