Pattern Glossary
This glossary defines the patterns used at each layer of the system and the dependency rules that govern them. It largely adopts architectural and design patterns articulated by Martin Fowler, Robert C. Martin, Paul M. Jones, Larry Constantine, Alistar Cockburn, Eric Evans, Vlad Khononov, and many others.
One thing the reader may notice, there is a lot of granularity. That is intentional. It serves multiple roles and provides practical conveniences. Notably, these patterns afford adherence to the Single Responsibility Principle (SRP, part of SOLID) without creating an unmanageable number of files or classes or leaving uncertainty about their proper placement.
We follow Hexagonal architecture
Section titled “We follow Hexagonal architecture”- Whether it is a modular monolith, a microservice, or a tiny processing service, we generally use hexagonal architecture as a baseline.
We follow Domain Driven Design architecture Lite
Section titled “We follow Domain Driven Design architecture Lite”- We tend to follow DDD, especially in modular monolith applications. We want the modules to be modeled like domains, that can be pulled off as microservices if the need is presented.
Patterns to Expect in the Application Layer
Section titled “Patterns to Expect in the Application Layer”- Actions (single-route controllers)
- Responders (DTO shaping)
- Listeners (event entry points)
- Webhooks (external HTTP entry points)
- API contracts and validation
Patterns to Expect in the Domain Layer
Section titled “Patterns to Expect in the Domain Layer”- Domain Services (orchestration)
- Aggregators (via ports)
- Transaction Scripts (business rules + param owners)
- Mappers (coordinate assembly)
- Assemblers (compose data)
- Converters (pure transforms)
- Entities and value objects
Patterns to Expect in the Infrastructure Layer
Section titled “Patterns to Expect in the Infrastructure Layer”- Repositories (return entities or projections, never DTOs)
- External IO adapters
- Dispatchers (publish domain events)
- Remote Callers (send commands to other systems)
Overall Pattern Pallete
Section titled “Overall Pattern Pallete”
Dependency Direction Principles
Section titled “Dependency Direction Principles”
Type Ownership & Flow Boundaries
Section titled “Type Ownership & Flow Boundaries”
Design Goals
Section titled “Design Goals”- Keep type ownership local
- Prevent shared-type dumping grounds
- Ensure dependencies point inward
- Make circular dependencies structurally impossible
- Keep controllers SRP-compliant by refactoring methods into single-purpose Action classes