# Rule 3: References by Identity > [!Note] > By storing only the **identifiers** of related [[Aggregate]], we **decouple models**, **load dependencies on demand**, and preserve **clear boundaries** for independent evolution. An [[Aggregate]] should never embed the internal state of another [[Aggregate]]; instead, it holds only that [[Aggregate]]’s **ID**, preventing unwanted coupling and ensuring each model remains autonomous. When related data is needed, a **repository** fetches the external Aggregate on demand, avoiding unnecessary loading and reducing memory overhead. This approach upholds strict **aggregate boundaries**, controls the propagation of changes, and allows each [[Aggregate]] to evolve independently without risking unintended side effects. --- ## References - Vernon, V. (2016). _Domain-driven design distilled_. Addison-Wesley Professional. - Vernon, V. (2013). _Implementing domain-driven design_. Addison-Wesley Professional. - Khononov, V. (2021). _Learning domain-driven design: Aligning software architecture and business strategy_. O’Reilly Media. - Alammar, J., & Grootendorst, M. (2024). _Hands-on large language models: Language understanding and generation_. O’Reilly Media. - Evans, E. (2003). _Domain-driven design: Tackling complexity in the heart of software_. Addison-Wesley Professional. - Millett, S., & Tune, N. (2015). _Patterns, principles, and practices of domain-driven design._ Wrox.