modular-architecture

# Modular Architecture

## When to Use This Skill

Use this skill when you need to:

- Structure a modular monolith application
- Define boundaries between modules (bounded contexts)
- Set up inter-module communication patterns
- Implement ports and adapters (hexagonal) architecture
- Isolate database contexts between modules
- Configure MediatR for internal domain events

**Keywords:** modular monolith, modules, bounded contexts, ports and adapters, hexagonal architecture, module communication, data isolation, separate DbContext, MediatR, domain events, internal events, module boundaries

## Module Structure Pattern

### Core Principle

Organize code by **modules (business capabilities)**, not layers. Each module is a self-contained vertical slice with its own:

- Domain entities and value objects
- Application services and handlers
- Infrastructure implementations
- Data transfer objects for external communication

### Standard Module Layout

```text
src/
├── Modules/
│   ├── Ordering/
│   │   ├── Ordering.Core/           # Domain + Application
│   │   │   ├── Domain/              # Entities, Value Objects, Events
│   │   │   ├── Application/         # Commands, Queries, Handlers
│   │   │   └── Ports/               # Interfaces (driven/driving)
│   │   ├── Ordering.Infrastructure/ # External dependencies
│   │   │   ├── Persistence/         # EF Core, DbContext
│   │   │   └── Adapters/            # External service implementations
│   │   └── Ordering.DataTransfer/   # DTOs for module-to-module communication
│   ├── Inventory/
│   │   ├── Inventory.Core/
│   │   ├── Inventory.Infrastructure/
│   │   └── Inventory.DataTransfer/
│   └── Shared/                      # Truly shared kernel (minimal)
│       └── Shared.Kernel/           # Common value objects, interfaces
└── Host/                            # Composition root, startup
    └── Api/                         # Controllers, middleware
```

### Key Principles

1. **No cross-module domain references** - Modu