Domain centric architectures, like clean architecture, have inner architectural cores that model the domain. Dependency inversion is king, with inner layers defining abstractions and interfaces and outer layers implementing them. Clean architecture is a good fit when aligning to Domain Driven Design (DDD), dealing with complex business logic, high testability is desirable and/or working in a large team, as the architecture can enforce design policies.
Glossary Guiding Principles Clean Architecture Layers Domain layer Entities Value Objects Domain Events Application layer Infrastructure layer Presentation layer .NET Implementation Tips Records Glossary Term Definition Aggregate A cluster of domain objects that can be treated as a single unit. An aggregate has one aggregate root and enforces consistency boundaries. Aggregate Root The only member of an aggregate that outside objects are allowed to hold references to. It controls access to the aggregate’s internals. Anemic Domain Model An anti-pattern where domain objects contain little or no business logic, acting mainly as data containers with getters and setters. Application Service A service in the application layer that orchestrates domain objects and infrastructure to fulfill use cases. Bounded Context A central pattern in DDD that defines explicit boundaries within which a domain model is valid and consistent. Clean Architecture An architectural pattern that separates concerns into concentric layers, with dependencies pointing inward toward the domain. Command An object that represents a request to perform an action, often used in CQRS to separate write operations. Context Map A visual representation showing the relationships and integration patterns between different bounded contexts. CQRS Separating read and write operations into different models and potentially different databases. Dependency Inversion A principle stating that high-level modules should not depend on low-level modules; both should depend on abstractions. Domain The subject area or sphere of knowledge and activity around which the application logic revolves. Domain Event Something that happened in the domain that domain experts care about and that triggers side effects. Domain Model An object model of the domain that incorporates both behavior and data, representing the business concepts and rules. Domain Service A service that encapsulates domain logic that doesn’t naturally fit within a single entity or value object. Entity A domain object that has a distinct identity that runs through time and different states. Event Sourcing A pattern where state changes are stored as a sequence of events rather than just the current state. Hexagonal Architecture Also known as Ports and Adapters, isolates the core business logic from external concerns through well-defined interfaces. Infrastructure Layer The outermost layer containing technical details like databases, external APIs, and frameworks. Onion Architecture Similar to Clean Architecture, organizing code in concentric layers with dependencies pointing inward. Port An interface that defines how the application core communicates with external systems (part of Hexagonal Architecture). Query In CQRS, a request for data that doesn’t change system state, optimized for reading operations. Repository A pattern that encapsulates the logic needed to access data sources, centralizing common data access functionality. Rich Domain Model A domain model where business logic is encapsulated within domain objects rather than external services. Saga A pattern for managing long-running business processes that span multiple aggregates or bounded contexts. Specification Pattern A pattern used to encapsulate business rules and criteria that can be combined and reused. Ubiquitous Language A common language shared by developers and domain experts within a bounded context. Use Case A specific way the system is used by actors to achieve a goal, often implemented as application services. Value Object An object that describes characteristics or attributes but has no conceptual identity. Guiding Principles High level qualities that a good software architecture should (and enforce) strive for; maintainability, testability and loose coupling.
...