In Eric Evans' [[Reccommended Reading#Domain Driven Design|blue book]], he outlines ways in which an application (presumably one written in Java) can be modeled following DDD principles. Many of the examples don't completely translate to today's microservices architectures but broadly speaking, there is a lot to learn. # Building Blocks An application can be decomposed into several different discrete building blocks—each with their own qualities that aid in development: - [[#Entities]] - [[#Value Objects]] - [[#Services]] - [[#Modules]] ## Entities Entities are objects that are bound to a specific identity. An entity is a unique object like a Customer, an Order, or some other concrete object we need to interact with. Every entity must have a way of uniquely identifying it. In most cases this will take the form of an ID define by a database or another algorithm such as [UUID](https://www.techtarget.com/searchapparchitecture/definition/UUID-Universal-Unique-Identifier#:~:text=A%20UUID%20(Universal%20Unique%20Identifier,UUID%20generated%20until%20A.D.%203400.). ## Value Object A Value Object is an object in the code that doesn't have a unique identity. These could be things like the letter "`Q`" or a date object. These items don't have a unique identity and could in fact be interchanged between entities (so long as their values are identical). Since two (2) entities could, in theory, share a in-memory *reference* to the same Value Object, we can eliminate the need to maintaining two copies of the object. Value objects can be easily serialized and stored in durable storage and brought back out again very easily. ## Services ## Modules # Aggregates > Cluster [[Modeling#Entities|Entities]] and [[Modeling#Value Object|Value Objects]] into Aggregates and define boundaries around each. Choose one [[Modeling#Entities|Entity]] to be the root of each Aggregate, and control all access to the objects inside the boundary through the root. > — [[Reccommended Reading#Domain Driven Design|Domain Driven Design]] pg 129 Aggregates act as a **transactional boundary**. Group Entities that need to have **strongly consistent data** into aggregates.