ddd standard architecture rules

DDD Standard Architecture Rules

1. Overall Architecture and Layer Definitions

1. The system must be clearly divided into Domain、Application、Infrastructure、Presentation four layers.
2. Each file may belong to only one layer and must not simultaneously bear responsibilities of multiple layers.
3. The purpose of layering is to isolate "business intent" from "technical details," and layers must not be merged for convenience.
4. Architectural design must aim at long-term evolution and minimizing replacement cost.

2. Dependency Direction (Must Not Be Violated)

1. Only the following unidirectional dependencies are allowed:
   Domain → Application → Infrastructure → Presentation
2. Any reverse dependency is to be regarded as an architectural error.
3. Reverse dependencies must not be formed indirectly through types, utility functions, barrel exports, or side effects.
4. Dependency direction must be statically analyzable at the TypeScript import level.

3. Domain Layer Rules (Business Core)

1. The Domain layer must be pure TypeScript.
2. The Domain layer must not depend on Angular, RxJS, Signals, HTTP, Storage, or any framework.
3. The Domain layer must not have async / await、Promise or I/O behavior.
4. The Domain layer only describes "what the business is," not "how it is done."
5. The Domain layer may contain only:
   • Entity
   • Value Object
   • Domain Service
   • Domain Interface
6. An Entity must have a clear identity.
7. A Value Object must be immutable.
8. A Domain Service may express only business rules that cannot naturally belong to a single Entity.
9. A Domain Interface only describes capabilities, not implementation methods.
10. The Domain layer must not know where data comes from, how it is stored, or how it is displayed.

4. Application Layer Rules (Business Processes and State Coordination)

1. The Application layer is responsible for "Use Cases" and business process orchestration.
2. The Application layer is the sole holder of the truth of business state for the entire system.
3. The Application layer may depend on the Domain, but must not reversely depend on Presentation or Infrastructure implementations.
4. The Application layer may depend only on interfaces defined by Infrastructure defined interface, not concrete classes.
5. The Application layer is responsible for transaction boundaries and process order.
6. The Application layer must not contain concepts related to UI, DOM, Component, or Template.
7. The Application layer must not contain data access details.
8. The Application layer must not leak framework types to other layers.
9. Application Facade is the only entry point that Presentation is allowed to access.

5. Infrastructure Layer Rules (Technical Implementation)

1. The Infrastructure layer is responsible only for implementing interfaces defined by the Domain or Application.
2. The Infrastructure layer may depend on frameworks and third-party packages.
3. The Infrastructure layer must not contain business rules or decision logic.
4. The Infrastructure layer must not itself become the source of truth for state.
5. The Infrastructure layer must not require upper layers (Application / Domain) to adjust their design to accommodate technical details.
6. The Infrastructure layer must not expose framework-specific types externally.
7. The Infrastructure layer can be replaced without affecting the Domain and Application.

6. Presentation Layer Rules (UI and Interaction)

1. The Presentation layer is responsible only for display and user interaction.
2. The Presentation layer must not contain business rules.
3. The Presentation layer must not define business state truth on its own.
4. The Presentation layer may only depend on the Application Facade.
5. The Presentation layer must not directly call Infrastructure.
6. The Presentation layer must not bypass Application to directly operate on Domain.
7. The Presentation layer's state may only be short-lived UI state.

VII. State and Responsibility Boundaries

1. The Domain layer does not hold application state.
2. The Application layer centrally manages all business state.
3. The Infrastructure layer must not hold long-lived business state.
4. The Presentation layer must not hold business state that spans pages or flows.
5. Any state may only have a single source of authority (Single Source of Truth).

VIII. Interface and Abstraction Rules

1. The definition location of an Interface must belong to the requester, not the implementer.
2. For capabilities that Application needs, their interface must be defined in Application or Domain.
3. Infrastructure may only implement interfaces and must not define requirements in reverse.
4. Interfaces must not leak technical details.

IX. Shared and Common Module Rules

1. shared must not become a business core.
2. shared must not contain business state or decisions.
3. If shared is regarded by multiple features as a business dependency, its layer must be moved up to Application or Domain.
4. shared may only contain:
   • Pure utilities
   • Pure UI
   • Pure stateless components

X. Structural and Naming Consistency

1. The folder structure must reflect layering and responsibility.
2. File names and folder names must allow direct inference of the layer to which they belong.
3. Naming whose semantics do not match actual responsibility must not appear.
4. Barrel exports must not blur layer boundaries.

XI. Validation and Evolution Rules

1. Domain must be able to compile and be tested independently of any framework.
2. Application must be able to run and be tested without a UI.
3. Infrastructure must be mockable or replaceable.
4. Replacing Presentation must not affect business logic.
5. Architecture rules must be checkable through lint, test, or CI.