Questions 76-100: DDD Boundaries, Resilience, Caching & Practical ASP.NET Core Design.
Open a question for the full answer, code and interview guidance.
A Bounded Context is an explicit boundary within which a particular domain model and its terminology are valid. The same real-world concept can have different models and meanings in different contexts.
Ubiquitous Language is a shared vocabulary used by developers and domain experts to describe the business model. The same terminology should appear in conversations, requirements, code, tests, and documentation within a bounded context.
A Context Map documents the relationships and integration boundaries between bounded contexts. It helps teams understand which context owns which model and how information flows between them.
An Anti-Corruption Layer protects one model from concepts and structures belonging to another system or bounded context. It translates external contracts into the language and types expected by the local domain.
No. In Domain-Driven Design, repositories are commonly associated with aggregate roots rather than every entity or database table. Internal entities should normally be loaded and modified through their aggregate root.
A domain repository exposes operations meaningful to a particular aggregate or business use case. A generic CRUD repository exposes broad operations such as Add, Update, Delete, and Get for arbitrary entity types.
An Application Service coordinates a use case. It loads domain objects, invokes domain behavior, calls required collaborators, and persists the resulting changes.
An Application Service orchestrates a complete application use case and may interact with repositories, transactions, messaging, or authorization. A Domain Service implements business logic that belongs to the domain but does not fit naturally on one entity or value object.
An anemic domain model contains entities that mainly expose data while business rules are implemented elsewhere in procedural service classes. The entities behave more like data containers than domain objects.
A rich domain model combines state with business behavior and protects invariants through meaningful methods. Instead of exposing unrestricted setters, entities and value objects control valid state transitions.
An invariant is a business rule that must remain true whenever an aggregate is in a valid state. The aggregate should prevent operations that would violate its invariants.
The Outbox Pattern helps make database changes and messages reliable without requiring one distributed transaction. The application stores the business change and an outgoing message record in the same local database transaction.
An operation is idempotent when repeating the same request does not create additional unintended effects after the first successful application. It is important because networks, retries, queues, and message brokers can cause duplicate delivery.
The Retry Pattern repeats an operation after a transient failure that may succeed later, such as a temporary network interruption or service throttling. Retries should normally use limits and suitable delays or backoff.
The Circuit Breaker Pattern temporarily stops calls to a repeatedly failing dependency. After a failure threshold, the circuit opens and fails fast instead of continuing to overload the unavailable service.
Retry assumes a failure may be temporary and repeats the operation. Circuit Breaker detects sustained failure and temporarily prevents additional calls.
The Timeout Pattern limits how long an application waits for an operation or dependency. Without a timeout, slow downstream services can consume threads, connections, and request capacity for too long.
The Bulkhead Pattern isolates resources so failure or heavy load in one part of a system does not consume all capacity needed by other parts. The name comes from compartments in ships that limit flooding.
In Cache-Aside, application code first checks the cache. On a cache miss, it reads from the primary data source and then stores the result in the cache for future requests.
A caching decorator implements the same interface as the underlying service or repository. It checks the cache first and delegates to the wrapped implementation only when necessary.
A decorator can execute cross-cutting behavior before or after delegating to the wrapped service. For example, a logging decorator can measure execution time, while a validation decorator can reject invalid input before the core service runs.
ASP.NET Core middleware forms an ordered request pipeline in which each component can process the request and optionally invoke the next component. This closely resembles the Chain of Responsibility pattern.
ASP.NET Core's DI container lets classes receive dependencies through abstractions rather than constructing infrastructure directly. This can support Dependency Inversion, improve testability, and make implementations replaceable.
Start with the actual change pressure, coupling, complexity, and business requirement. If a constructor, method, or small service solves the problem clearly, introducing a formal pattern may only add indirection.
First identify responsibilities and reasons for change rather than splitting the class only by line count. Separate business rules, persistence, external integrations, notifications, and cross-cutting concerns into cohesive components with clear boundaries.