Questions 101-125: Architectural Patterns, Application Boundaries & Distributed Design Patterns.
Open a question for the full answer, code and interview guidance.
Layered Architecture organizes an application into logical layers such as presentation, application/business logic, and data access. Each layer has a defined responsibility and normally communicates with adjacent or permitted layers.
Clean Architecture organizes software so business rules are independent of frameworks, databases, user interfaces, and other external details. Dependencies point inward toward more stable application and domain policies.
Onion Architecture places the domain model at the center and arranges application and infrastructure concerns in surrounding layers. Dependencies point inward, so outer technical details depend on inner abstractions.
Hexagonal Architecture, also called Ports and Adapters, separates application logic from external systems through explicit ports. Adapters implement those ports for technologies such as databases, HTTP APIs, messaging systems, or user interfaces.
Clean, Onion, and Hexagonal Architecture use different terminology and diagrams, but all emphasize protecting core business logic from infrastructure details and controlling dependency direction.
The Dependency Rule states that source-code dependencies should point toward inner, more stable policy layers. Inner layers should not know about outer frameworks or infrastructure implementations.
An interface should normally be owned by the layer that needs the abstraction, not automatically by the class that implements it. If the application layer needs persistence behavior, the persistence port can live in Application or Domain depending on the design.
Ports and Adapters separates the application core from external technologies. A port describes how the core communicates with the outside world, while an adapter connects that port to a specific technology.
A Modular Monolith is deployed as one application but internally divided into strongly separated business modules. Each module owns its logic and should expose deliberate contracts rather than allowing unrestricted access to its internals.
A traditional monolith may allow features to share database tables, classes, and services freely, which can create strong internal coupling. A Modular Monolith intentionally establishes module boundaries and controlled communication while retaining one deployment unit.
The Service Layer Pattern defines an application boundary containing operations available to clients. It coordinates use cases and separates controllers or UI code from domain and persistence details.
A DTO is an object designed to transfer data across application or process boundaries without exposing internal domain or persistence objects directly. DTOs usually contain data rather than domain behavior.
API models are external contracts, while domain entities represent internal business concepts and invariants. Using one type for both can couple API versioning and serialization concerns directly to the domain.
Mapping translates data between models that serve different responsibilities, such as API DTOs, application models, domain objects, and persistence representations. It prevents those boundaries from becoming the same model accidentally.
The Result Pattern represents an operation's success or expected failure explicitly instead of using exceptions for every business outcome. A result can contain a value on success and structured errors on failure.
The Options Pattern provides strongly typed access to related configuration values. Configuration sections are bound to classes that can be injected through options abstractions.
A Specification can package query criteria and related query decisions into a reusable object instead of duplicating complex filters across repositories or services.
The Saga Pattern coordinates a business transaction that spans multiple independent operations or services without relying on one distributed ACID transaction. A saga consists of steps and, when necessary, compensating actions for previously completed steps.
In orchestration, a central saga coordinator tells participants which step to execute and decides what happens next. In choreography, participants react to events and publish new events without one central workflow controller.
Event Sourcing stores a sequence of domain events as the authoritative history of an aggregate instead of storing only its latest state. Current state is reconstructed by replaying those events, often with snapshots for efficiency.
Event Sourcing is a persistence model in which events are the source of truth for state. Event-driven architecture is a communication style in which components publish and react to events.
The Strangler Fig Pattern incrementally replaces a legacy system by routing selected functionality to new components while the old system continues to serve the remaining functionality.
The Backend for Frontend pattern provides a backend tailored to the needs of a particular client experience, such as web, mobile, or an administrative application. The BFF can aggregate downstream calls and expose client-specific data shapes.
An anti-pattern is a recurring approach that appears useful but commonly produces negative consequences in a particular context. Examples can include God Objects, Service Locator misuse, excessive shared mutable state, or premature abstraction.
A God Object is a class that accumulates too many responsibilities, dependencies, and reasons to change. It often knows about persistence, validation, calculations, external services, formatting, and workflow coordination at the same time.