cleanddd-modeling

CleanDDD Modeling Skill

Based on user requirements, design a business model that conforms to CleanDDD principles, including aggregates, commands, events, queries, etc., ensuring the model's clarity and maintainability.

Prerequisite Inputs

• Existing cleanddd-requirements-analysis structured results (stakeholder table, requirements item table, business entity view, trigger/follow-up action table, business rules and dependencies, assumptions and to-be-confirmed list); if missing, first run the requirements analysis skill and complete confirmation.
• The classification of requirements items/business entities has been confirmed with the user or assumptions have been noted.

When to Use

• When structured requirements need to be mapped to CleanDDD aggregate/command/query/event/Endpoint and scheduled task designs.

Input Mapping Relationships

• Business entity view → aggregate candidates and responsibilities/invariants
• Requirements item table → commands/queries and inputs/outputs, idempotency
• Trigger/follow-up action table → domain events (DomainEvent) and event handlers
• Stakeholder table → authentication/authorization scope and interaction scenarios for API endpoints (Endpoints)
• Business rules and dependencies → consistency/side-effect descriptions and external dependency annotations
• Assumptions and to-be-confirmed list → "open issues/assumptions" and follow-up question list in modeling

Workflow

1. Input validation: confirm that the requirements item table, business entity view, and trigger/follow-up action table are complete; for gaps, first ask follow-up questions or note assumptions.
2. Aggregate definition: based on responsibilities and invariants, define aggregate roots, entities/value objects, behaviors, and triggered domain events; keep no direct references between aggregates.
3. Commands and queries: map each requirements item to commands/queries, using PascalCase for naming; specify inputs/outputs, idempotency, and involved aggregate behaviors.
4. Domain events and handlers: based on the trigger/follow-up action table, list domain events (DomainEvent), subscribers, and handling actions; avoid direct operations across aggregates and use domain event-driven approaches.
5. API endpoints (Endpoints): for external interactions, complete the HTTP Method, authentication, idempotency, and bound commands/queries; specify default sorting/pagination.
6. Scheduled tasks: if there are periodic requirements, define task names, frequencies, and triggered commands/queries.
7. Naming and constraint checks: use PascalCase for aggregates/commands/events/queries; confirm there are no shared entities and only shared value objects; use past tense for event naming.

Output Format (structured Markdown, convenient for code generation)

• Aggregates
  • Name | Responsibility summary | Key invariants
  • Entity/Value Object | Attributes (including default values/optional values) | Behaviors | Triggered domain events (DomainEvent)
• Commands
  • Name | Target aggregate | Input | Triggered behavior/event | Idempotency
• Queries
  • Name | Target aggregate | Filtering/Sorting/Pagination | Output DTO or Response
• Event Handlers (DomainEventHandlers)
  • Domain event (DomainEvent) | Subscriber | Handling action | Side effects/external dependencies
• API Endpoints (Endpoints)
  • Path/Method | Command/Query | Authentication/Authorization | Idempotency/Consistency description
• Scheduled tasks (if any)
  • Name | Frequency | Triggered command/query | Idempotency/Compensation

Unified naming and placement conventions

• Naming style: Use PascalCase for aggregates/commands/events/queries/endpoints; event names use the past tense.
• Documentation output: Use the structured Markdown from the "Output Format" section above, to facilitate subsequent automatic code generation and review.
• Terminology consistency: Consistently use terms such as "API Endpoints", "DomainEvent", and "DomainEventHandlers".
• Delivery handoff: The output files of this skill should serve as the input basis for cleanddd-dotnet-coding ; regarding file naming and directory placement, see that skill's "Unified naming and placement conventions".

Core principles

• Clear boundaries: Aggregates do not directly or indirectly reference each other.
• Entity sharing restriction: Aggregates do not share entities; sharing value objects is allowed.
• Domain event principle: Domain events are produced by aggregate behavior; cross-aggregate impact is achieved through domain events for eventual consistency.
• Key invariants: Validate before aggregate behavior; no state change may violate them.
• Naming conventions: Use PascalCase for aggregates/commands/events/queries, and use the past tense for events.
• API endpoint authentication (Endpoints): Determine the authentication scope and idempotency based on the stakeholder table and requirements item table.

Delivery and confirmation

• Append a "Parameter summary + whether to execute" prompt at the end to ensure the user confirms before proceeding to cleanddd-dotnet-coding.
• List open questions or assumptions to avoid omissions in the subsequent coding phase.