Glossary

Every term from the three approaches, defined simply and linked back to the articles that explain them in depth.

36 terms

Adapter: Concrete technical implementation of a port: a REST controller, a PostgreSQL repository, an email client. The domain doesn't know which one is plugged in at a given time.
Aggregate: Group of entities and value objects that must stay consistent together at all times, with a single root guaranteeing the invariants.
Aggregate Root: The only entity of an aggregate accessible from the outside. Any access to the aggregate's internal objects must go through it.
Anemic Domain Model: Anti-pattern where entities are just data bags with getters/setters, with all business logic pushed out into external services.
Anticorruption Layer (ACL): Translation layer built by a context to protect itself from an external model it doesn't want polluting its own business language.
Big Ball of Mud: A system with no clear boundary or structure, where everything depends on everything. Exactly what ports/adapters, circles, and bounded contexts try to avoid.
Bounded Context: Explicit boundary within which a given model is valid and consistent. The same word ("Customer") can mean different models in different contexts.
Conformist: Context mapping relationship where a downstream context accepts an upstream model as-is, with no room for negotiation.
Context Mapping: Explicit description of the relationships between several bounded contexts: Shared Kernel, Customer/Supplier, Conformist, Anticorruption Layer, Open Host Service.
Coupling and cohesion: Coupling measures how much two components depend on each other; cohesion measures how much the elements of one component share a single clear responsibility. All three approaches aim for low coupling and high cohesion.
Customer / Supplier: Relationship where an upstream context (supplier) provides data or services to a downstream context (customer), which can influence its roadmap.
Dependency Inversion Principle: SOLID principle stating that high-level modules shouldn't depend on low-level modules, but both on abstractions. The shared technical foundation of hexagonal and Clean Architecture.
Dependency Rule: Central principle of Clean Architecture: source code in a circle can only reference elements in the same circle or a more inner one. Never the reverse.
Domain core: The center of the hexagon: entities, business rules, use cases. It depends on no framework, no database, no technical library.
Domain Event: A fact that happened in the domain, named in the past tense (OrderPlaced). Lets other parts of the system react without direct coupling.
Domain Service: A business operation that doesn't naturally belong to any single entity, such as transferring an amount between two distinct accounts.
Driven port (Secondary port): A port the domain defines because it needs something from the outside: persisting data, sending a message. The domain sets the shape of the interface.
Driving port (Primary port): A port that lets the outside operate the domain: typically a use case interface, called by a controller, a CLI, or a test.
Entities (Clean Architecture circle): The innermost circle: the most general business rules of the enterprise, the ones that would survive a complete change of application.
Entity (DDD sense): Object defined by its identity, which persists over time even as its attributes change. An Order stays the same order whether a line is added or not.
Event Storming: Collaborative workshop where developers and domain experts lay out domain events together, on sticky notes, to discover the model and the bounded contexts.
Factory: Encapsulates complex or rule-bound creation logic, when a plain constructor is no longer enough to guarantee a valid object.
Framework independence: The ability of business code to run, be understood, and be tested without depending on a particular framework - a goal shared by all three approaches.
Frameworks & Drivers: The outermost circle of Clean Architecture: database, web framework, user interface. Kept to a minimum, mostly wiring.
Gateway: Term used in Clean Architecture for an interface a use case defines toward the outside - the direct equivalent of a driven port in hexagonal architecture.
Interface Adapters: Translation layer between the format convenient for use cases and the format convenient for external technology: controllers, presenters, mappers.
Onion Architecture: Architecture proposed by Jeffrey Palermo, a direct cousin of hexagonal and Clean Architecture: concentric layers with dependencies pointing toward the center.
Open Host Service: A context that exposes a well-defined public protocol, designed to be consumed by several other contexts without individual coordination.
Port: Interface defined by the domain to communicate with the outside, in strictly business vocabulary. There are two kinds: driving (what the domain offers) and driven (what it needs).
Presenter: Component in the Interface Adapters layer that formats a use case's result for display, carrying no business rule of its own.
Repository: Gives the illusion of an in-memory collection for a given aggregate (save, findById). Always maps to an aggregate root, never to an internal entity.
Shared Kernel: Context mapping relationship where two teams deliberately share a small portion of a common model, accepting the coordination cost.
Testability: How easily a business rule can be verified by a fast automated test, with no database or server - one of the direct benefits of isolating the domain.
Ubiquitous Language: Precise vocabulary shared between developers and domain experts, used without translation, all the way into class and method names in the code.
Use Case (Interactor): Application-specific orchestration ("place an order", "cancel a subscription"). Uses entities and defines, through interfaces, what it needs from the outside.
Value Object: Object defined solely by its attributes, with no identity of its own, and immutable by construction. Two Money instances of "10 EUR" are interchangeable.