ddd-domain-model-extractor

Analyze the existing code in phases: map the directory structure, inspect data structures and DB schemas, locate scattered business logic, and identify transaction boundaries. Then derive value objects, aggregates, local entities, and domain services from those signals.

Look for data groups always updated within the same transaction, classes that form CRUD units, and objects accessed directly rather than through a parent. Tables referenced by foreign keys are aggregate root candidates, while child tables accessed only via parents become local entities.

An aggregate has a root ID, is retrieved independently, and defines a consistency boundary. A local entity has its own ID but is only accessed through its parent aggregate and shares the parent's lifecycle.

Yes, the analysis is language-independent. It works from structural signals like classes, database schemas, and transaction boundaries, and outputs language-agnostic pseudocode rather than framework-specific implementations.

Avoid mapping one class or table to one aggregate. Multiple classes may form a single aggregate, one class may split into several, and table structures reflect persistence concerns rather than domain boundaries. Keep aggregates small and split when in doubt.