Domain-Driven Design (DDD)

--- name: domain-driven-design description: Apply Domain-Driven Design principles for modeling complex business domains version: 1.0.0 author: wondelai (adapted) platforms: [claude-code, cursor] license: MIT source: https://github.com/wondelai/skills based_on: "Domain-Driven Design by Eric Evans" --- # Domain-Driven Design (DDD) Apply DDD principles to model complex business domains effectively. ## Scoring System Rate the design 0-10 on DDD alignment. Show: current score → issues → improved model → explanation. ## Strategic Design ### Bounded Context A Bounded Context is a boundary within which a particular domain model applies. Names mean different things in different contexts. ``` Example: "Customer" in Sales context = contact with purchasing history "Customer" in Support context = ticket submitter with SLA level → These are different models, different tables, different services ``` Identify contexts by asking: - Which teams work on which parts? - Where do the same words mean different things? - Where does consistency matter vs where is eventual consistency fine? ### Context Map Patterns - **Shared Kernel** — two contexts share a subset of the domain model - **Customer/Supplier** — upstream context defines API, downstream adapts - **Anti-Corruption Layer** — translation layer to protect your model from a legacy system - **Published Language** — shared canonical data format between contexts ## Tactical Design ### Aggregates The root entity that owns consistency: ```python class Order: # Aggregate Root def __init__(self, order_id: OrderId, customer_id: CustomerId): self.id = order_id self.customer_id = customer_id self._items: list[OrderItem] = [] # child entities self._events: list[DomainEvent] = [] def add_item(self, product: Product, quantity: int) -> None: # Business rule enforced here, not in service if quantity <= 0: raise ValueError("Quantity must be positive") self._items.append(OrderItem(product.id, quantity, product.price)) ``` Rules: - Only reference other aggregates by ID, not by object reference - Transactions should not cross aggregate boundaries - Keep aggregates small ### Value Objects Immutable objects defined by their attributes: ```python @dataclass(frozen=True) class Money: amount: Decimal currency: str def __add__(self, other: 'Money') -> 'Money': if self.currency != other.currency: raise ValueError("Cannot add different currencies") return Money(self.amount + other.amount, self.currency) ``` ### Domain Events Something that happened in the domain: ```python @dataclass class OrderPlaced: order_id: str customer_id: str total_amount: Money occurred_at: datetime ``` ### Repository Pattern Abstract persistence from domain logic: ```python class IOrderRepository(Protocol): def get(self, order_id: OrderId) -> Order: ... def save(self, order: Order) -> None: ... def find_by_customer(self, customer_id: CustomerId) -> list[Order]: ... ``` ## Common Anti-Patterns - **Anemic Domain Model** — entities with only getters/setters, all logic in services - **Fat Service Layer** — services that contain all business rules - **God Object** — one entity that knows everything - **Primitive Obsession** — using `str` for email, `int` for money, etc.

/domain-driven-design

Помоги спроектировать агрегат Order для e-commerce с правилами скидок
/domain-driven-design

Проведи DDD-ревью этого кода сервиса
/domain-driven-design