software-design-ddd-domain-modeling

# DDD Domain Modeling for Architecture ## Overview This skill is the architect-private **domain modeling workflow** for architecture design. Use it when the real difficulty is not selecting middleware, but deciding: - how the business should be split into domains and subdomains - where bounded contexts should begin and end - how contexts relate and where translation / anti-corruption is needed - where aggregate and consistency boundaries should sit - how those modeling decisions should appear in 概要设计 or 详细设计 rather than staying as abstract DDD vocabulary Core principle: **domain modeling is not a theory appendix; it is a design tool for reducing semantic and consistency ambiguity before implementation.** This skill is intentionally narrower than the architect general playbook. It does not try to own the whole architecture delivery chain. It specializes in the part of architecture work where domain boundaries and model structure dominate the design outcome. ## When to Use Use when: - the architecture task is at 概要设计 or 详细设计 stage and domain boundaries are still unclear - the user asks about 领域 / 子域 / 限界上下文 / 上下文映射 / 聚合 / 事件风暴 - the system has business complexity that cannot be explained well by component diagrams alone - service boundaries or ownership boundaries depend on language/model boundaries - multiple teams or subsystems disagree on concepts, state ownership, or consistency responsibility Do not use when: - the main problem is only delivery packaging or stage p...