domain-model-extractor

Domain Model Extractor

Analyze existing non-DDD code and propose DDD building blocks (aggregates, local entities, value objects, domain services) with pseudocode.

Analysis workflow

Phase 1: Scope confirmation

Confirm the following with the user:

• Directory/file scope to analyze
• Overview of the domain (what kind of system it handles)
• Areas of particular interest (if any)

Phase 2: Exploration of existing code

Collect information in the following order:

Step 1: Grasping the structure

• Check the directory structure and get an overall picture of the modules/packages
• List the main classes/structs/types

Step 2: Analysis of data structures

• Check the DB schema (migrations, ORM models, etc.) if available
• Check the fields/properties of the main classes/structs
• Grasp the reference relationships between data (foreign keys, ID fields, etc.)

Step 3: Locating business logic

• Identify scattered locations of validation logic
• Identify methods with many conditional branches (candidates for business rules)
• Identify operations that span multiple entities

Step 4: Analysis of transaction boundaries

• Identify the data groups updated within the same transaction
• This becomes the most important clue for aggregate boundaries

Phase 3: Deriving the domain model

Based on the collected information, derive the model in the following order. For detailed heuristics, refer to references/analysis-heuristics.md .

Derivation order:

1. Value objects - From domain concepts expressed as primitive types and scattered validation logic
2. Aggregates - From transaction boundaries, units of CRUD, and the scope of invariants
3. Local Entity - Objects that have meaning only within an aggregate and have an ID
4. Domain Service - Operations spanning multiple aggregates, rules that do not belong to a specific object

Information to include in each model:

• Properties (with type information)
• Factory methods (validation at creation time)
• Command methods (state-changing operations, returning a new instance immutably)
• Query methods (state-referencing operations)
• Invariants (rules the aggregate must always satisfy)

Phase 4: Output of the proposal document

references/output-template.md Following the template, generate a Markdown document that includes the following:

1. Overview (analysis targets, number of models discovered)
2. Section per aggregate (with pseudocode)
3. Value object list (with pseudocode)
4. Domain service list (with pseudocode)
5. Aggregate relationship diagram (text-based)
6. Mapping table with existing code

Output example (excerpt)

The following is an output image (for one aggregate) when analyzing EC site order management code:

Aggregate Order {
  id: OrderId
  customerId: CustomerId        // 他集約へのID参照
  items: List<OrderItem>        // ローカルエンティティ
  status: OrderStatus           // 値オブジェクト
  shippingAddress: Address      // 値オブジェクト

  // Invariants: items は1件以上、合計金額は0より大きい

  static create(customerId, firstItem, address): Order
  addItem(item: OrderItem): Order       // returns 新しいインスタンス
  removeItem(itemId: OrderItemId): Order
  submit(): Order                        // status を Submitted に変更
  totalAmount(): Money
}

Classification criteria

Decision point	Aggregate	Local Entity	Value object
Does it have its own ID	Yes (Root ID)	Yes (Local ID)	No
Is it retrieved independently	Yes	No (via parent)	No
Has Lifecycle	Yes	Subordinate to parent	None (immutable)
Is it compared by identity	Yes（ID）	Yes（ID）	No (compared by value)

Notes

• One class in existing code does not necessarily equal one aggregate. Multiple classes may form one aggregate, and one class may be split into multiple
• Do not be overly influenced by table structure. Tables are for persistence convenience and do not necessarily match the structure of the domain model
• Do not create excessively fine-grained value objects. Only units that are meaningful in the domain
• Keep aggregates small (Vernon's Rule). When in doubt, lean toward splitting

Related skills (recommended to read together)

When using this skill, also refer to the following skills:

• domain-building-blocks: Definition and design of building blocks to be extracted
• aggregate-design: Identification and design rules for aggregate boundaries
• cqrs-aggregate-modeling: Guidelines for separating aggregates with mixed read responsibilities