{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"What is the Clean Architecture principle?","acceptedAnswer":{"@type":"Answer","text":"Clean Architecture organizes code into concentric layers where dependencies point only inward (toward the domain). The Domain layer (entities, business rules) has no infrastructure dependencies. Outer layers (UI, Database, API) depend on domain abstractions via Dependency Inversion. This ensures testability, framework independence, and code maintainability."}},{"@type":"Question","name":"What are the main layers of Clean Architecture?","acceptedAnswer":{"@type":"Answer","text":"Clean Architecture has 4 main layers: Domain (entities, business rules, repository interfaces), Application (use cases, DTOs, application logic), Infrastructure (repository implementations, DbContext, external services), and Presentation (API controllers, UI). Domain is at the center and depends on nothing. Application depends on Domain. Infrastructure and Presentation depend on Application and Domain."}},{"@type":"Question","name":"What is the CQRS pattern?","acceptedAnswer":{"@type":"Answer","text":"CQRS (Command Query Responsibility Segregation) separates read (Queries) and write (Commands) operations. Commands modify state and return void or a simple result. Queries return data without modifying state. This separation allows independent optimization of reads (Dapper, SQL views) and writes (EF Core, DDD aggregates), and different scaling for each side."}},{"@type":"Question","name":"What is the role of MediatR in Clean Architecture?","acceptedAnswer":{"@type":"Answer","text":"MediatR implements the Mediator pattern to decouple Controllers from Handlers. Controllers send Commands/Queries via IMediator.Send(), and MediatR automatically routes to the correct Handler (IRequestHandler). This reduces coupling, centralizes application logic in Handlers, and allows adding cross-cutting behaviors (validation, logging, transactions) via the pipeline."}},{"@type":"Question","name":"How to define a Command in MediatR?","acceptedAnswer":{"@type":"Answer","text":"A Command implements IRequest where TResponse is the return type (often bool, int, or void via Unit). The Command is a record or class containing the data needed for the operation. Example: public record CreateOrderCommand(List Items, string UserId) : IRequest. The corresponding Handler implements IRequestHandler."}},{"@type":"Question","name":"What is the difference between a Command and a Query in CQRS?","acceptedAnswer":{"@type":"Answer","text":"A Command modifies system state (Create, Update, Delete) and typically returns a simple result (bool, int, void). A Query reads data without modifying state and returns a DTO or ViewModel. This separation respects CQS (Command Query Separation): a method modifies OR returns data, never both. Queries can use read optimizations (Dapper, denormalized views)."}},{"@type":"Question","name":"What is a Handler in MediatR?","acceptedAnswer":{"@type":"Answer","text":"A Handler implements IRequestHandler and contains the application logic to process a Command or Query. It receives the request via the Handle() method, executes business logic (validation, repository orchestration, domain events), and returns the result. MediatR automatically discovers Handlers via reflection during registration (AddMediatR())."}},{"@type":"Question","name":"What is the Repository Pattern?","acceptedAnswer":{"@type":"Answer","text":"The Repository Pattern abstracts data access via interfaces defined in the Domain layer. The implementation (with EF Core) resides in Infrastructure. This decouples the domain from persistence, allows changing the ORM without impacting business logic, and facilitates unit testing with mocked repositories. A repository exposes business methods (FindOrdersByUserId) rather than generic CRUD."}},{"@type":"Question","name":"What is the Unit of Work Pattern?","acceptedAnswer":{"@type":"Answer","text":"The Unit of Work Pattern manages transactions and coordinates saving multiple entities. In EF Core, DbContext already implements this pattern: SaveChanges() persists all changes in a transaction. It can be abstracted via IUnitOfWork to decouple from DbContext, but EF Core often makes this abstraction redundant. Useful for coordinating multiple repositories or different ORMs."}},{"@type":"Question","name":"How to register MediatR in ASP.NET Core?","acceptedAnswer":{"@type":"Answer","text":"Install the MediatR package and call builder.Services.AddMediatR(cfg => cfg.RegisterServicesFromAssembly(typeof(Program).Assembly)) in Program.cs. MediatR automatically scans the assembly to discover all Handlers (IRequestHandler) and registers them. Multiple assemblies can be scanned if Handlers are distributed (Application layer)."}},{"@type":"Question","name":"What is a Pipeline Behavior in MediatR?","acceptedAnswer":{"@type":"Answer","text":"A Pipeline Behavior implements IPipelineBehavior and intercepts all Commands/Queries before and after processing by Handlers. It allows adding cross-cutting concerns: validation (FluentValidation), logging, transaction management, performance monitoring. Behaviors execute in registration order and can short-circuit the pipeline (e.g., validation failure)."}},{"@type":"Question","name":"How to implement validation in MediatR with FluentValidation?","acceptedAnswer":{"@type":"Answer","text":"Create a ValidationBehavior implementing IPipelineBehavior. In Handle(), retrieve all validators for TRequest via DI, execute Validate(), collect errors with SelectMany(). If errors exist, throw ValidationException. Otherwise, call next() to continue the pipeline. Register the behavior with builder.Services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehavior<,>))."}},{"@type":"Question","name":"What is the difference between Queries with EF Core and Dapper in CQRS?","acceptedAnswer":{"@type":"Answer","text":"EF Core uses LINQ, change tracking, and generates SQL. Ideal for Commands (writes) with DDD aggregates. Dapper is a micro-ORM that executes raw SQL and directly maps results. Ideal for Queries (reads) as it's faster (no tracking), allows optimized SQL projections, and supports denormalized views. In CQRS, EF Core is often used for Commands and Dapper for Queries."}},{"@type":"Question","name":"How to manage transactions in Clean Architecture with EF Core?","acceptedAnswer":{"@type":"Answer","text":"SaveChanges() automatically executes in a transaction. For explicit transactions, use await using var transaction = await _context.Database.BeginTransactionAsync(), then await transaction.CommitAsync() on success. In CQRS, a Pipeline Behavior can manage transactions: BeginTransaction() before handler, CommitAsync() after if success, RollbackAsync() if exception. This avoids duplicating transactional logic in each handler."}},{"@type":"Question","name":"What is the Dependency Inversion Principle in Clean Architecture?","acceptedAnswer":{"@type":"Answer","text":"The Dependency Inversion Principle (DIP, SOLID) states that high-level modules (Domain) should not depend on low-level modules (Infrastructure), but both should depend on abstractions (interfaces). Domain defines IOrderRepository, Infrastructure implements OrderRepository. DI injects the concrete implementation at runtime. This allows testing the domain without database dependency."}},{"@type":"Question","name":"How to test a MediatR Handler with mocked repositories?","acceptedAnswer":{"@type":"Answer","text":"Use Moq to create repository mocks (Mock). Configure behavior with Setup() (e.g., Setup(x => x.GetByIdAsync(1)).ReturnsAsync(order)). Instantiate Handler passing mock.Object. Execute Handle() with a test command. Verify result with assertions (FluentAssertions) and verify calls with Verify() (e.g., Verify(x => x.AddAsync(It.IsAny()), Times.Once))."}},{"@type":"Question","name":"What is the purpose of DTOs (Data Transfer Objects) in Clean Architecture?","acceptedAnswer":{"@type":"Answer","text":"DTOs decouple the Presentation layer (API) from the Domain (entities). Entities contain business logic and navigation properties (EF Core), unsuitable for JSON serialization. DTOs are simple classes optimized for transfer (no logic, no navigation). This avoids over-fetching (N+1 queries), allows precise control of exposed data, and protects the domain model from API changes."}},{"@type":"Question","name":"How to organize projects in a Clean Architecture .NET solution?","acceptedAnswer":{"@type":"Answer","text":"Create 4 projects: Domain (entities, interfaces, no dependencies), Application (use cases, DTOs, MediatR handlers, depends on Domain), Infrastructure (repositories, DbContext, external services, depends on Application and Domain), and Presentation/API (controllers, depends on Application). Startup project is API. Infrastructure and API reference Application via DI. Domain remains independent of all frameworks."}},{"@type":"Question","name":"What is the difference between an Application Service and a Domain Service?","acceptedAnswer":{"@type":"Answer","text":"A Domain Service contains business logic that doesn't belong to a single entity (e.g., calculate total price with multi-country VAT). It stays in Domain and has no infrastructure dependencies. An Application Service (MediatR Handler) orchestrates use cases: retrieves entities via repositories, calls domain services, persists, publishes events. It coordinates but doesn't contain pure business logic."}},{"@type":"Question","name":"When to use Clean Architecture and CQRS?","acceptedAnswer":{"@type":"Answer","text":"Use Clean Architecture for complex projects requiring long-term maintainability, testability, and framework independence. CQRS is useful when read needs (reports, dashboards) differ from writes (business transactions), or to optimize reads/writes independently. Avoid for simple CRUD projects where it adds unnecessary complexity. Start simple and evolve if needed (YAGNI)."}}]}