|
Size: 1891
Comment:
|
← Revision 28 as of 2022-10-21 09:13:35 ⇥
Size: 3988
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = DomainDrivenDesign = | = Domain Driven Design (DDD) = * https://en.wikipedia.org/wiki/Domain-driven_design * https://martinfowler.com/bliki/DDD_Aggregate.html |
| Line 4: | Line 6: |
| the essence of DDD is profoundly simple: capture the domain model in domain terms, embed the model in the code, and protect it from corruption. | the essence of DDD is profoundly simple: capture the domain model in domain terms, embed the model in the code, and protect it from corruption. |
| Line 14: | Line 19: |
| '''Entity:''' Objects that have a distinct identity that runs through time and different representations. You also hear these called "reference objects". * Note: not the same as entities in ORM's |
=== Entity === Objects that have a distinct identity that runs through time and different representations. You also hear these called '''"reference objects"'''. * Note: not the same as entities in ORM's (exception @Entity in JPA) |
| Line 17: | Line 23: |
| '''Value Object:''' Objects that matter only as the combination of their attributes. Two value objects with the same values for all their attributes are considered equal. I also describe value objects in P of EAA. | === Value Object === Objects that matter only as the combination of their attributes. Two value objects with the same values for all their attributes are considered equal. I also describe value objects in P of EAA. |
| Line 20: | Line 27: |
| '''Service:''' A standalone operation within the context of your domain. A Service Object collects one or more services into an object. Typically you will have only one instance of each service object type within your execution context. * Note: business logic and business rules |
One important rule to follow is that '''value objects should be immutable'''. To change a value (such as my height) you don't change the height object, you replace it with a new one. |
| Line 25: | Line 31: |
| One important rule to follow is that value objects should be immutable. To change a value (such as my height) you don't change the height object, you replace it with a new one. | === Service === A standalone operation within the context of your domain. A Service Object collects one or more services into an object. Typically you will have only one instance of each service object type within your execution context. * Note: business logic and business rules |
| Line 27: | Line 35: |
| Service objects are often implemented by using global variables, class fields (monostates in Robert Martin's terminology) or singletons. | '''Service objects''' are often implemented by using global variables, class fields (monostates in Robert Martin's terminology) or '''singletons'''. == Springboot2 - hexagonal architecture == * https://www.baeldung.com/hexagonal-architecture-ddd-spring * application divided into three layers: * application (outside) * domain (inside) * infrastructure (outside): == application layer == * interaction with the application * has stuff like interfaces, RESTful controllers, and JSON serialization libraries * coordinates the execution of domain logic. == domain layer == * code that implements business logic * define the API to communicate with external parts, like the database == infrastructure layer == * app dependencies required to run the app * database configuration and Spring configuration. == DDD aggregates == * https://www.baeldung.com/spring-persisting-ddd-aggregates An aggregate is a '''group of business objects''' which always need to be consistent. Therefore, we save and update aggregates as a whole inside a transaction. An aggregate root is a class which works as an entry point to our aggregate. All business operations should go through the root. == Java JPA and DDD == * @Entity, is the same as the Entity in DDD and it '''has an identity''' * @Embeddable, is the same as a value object or value type, '''doesn't have an identity''' == Repository == * https://martinfowler.com/eaaCatalog/repository.html A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. * https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design Repositories are classes or components that encapsulate the logic required to access data sources. |
Domain Driven Design (DDD)
the essence of DDD is profoundly simple: capture the domain model in domain terms, embed the model in the code, and protect it from corruption.
- Understand the business, business logic independently of the tech used
- Capture the domain model, in domain terms, through interactions with domain experts.
- Embed the domain terminology in the code.
- Protect the domain knowledge from corruption by other domains, technical subdomains, etc.
EvansClassification
https://martinfowler.com/bliki/EvansClassification.html
Entity
Objects that have a distinct identity that runs through time and different representations. You also hear these called "reference objects".
- Note: not the same as entities in ORM's (exception @Entity in JPA)
Value Object
Objects that matter only as the combination of their attributes. Two value objects with the same values for all their attributes are considered equal. I also describe value objects in P of EAA.
- Note: Only constructor and getters. Immutable !
One important rule to follow is that value objects should be immutable. To change a value (such as my height) you don't change the height object, you replace it with a new one.
One clear division between entities and values is that values override the equality method (and thus hash) while entities usually don't.
Service
A standalone operation within the context of your domain. A Service Object collects one or more services into an object. Typically you will have only one instance of each service object type within your execution context.
- Note: business logic and business rules
Service objects are often implemented by using global variables, class fields (monostates in Robert Martin's terminology) or singletons.
Springboot2 - hexagonal architecture
- application divided into three layers:
- application (outside)
- domain (inside)
- infrastructure (outside):
application layer
- interaction with the application
- has stuff like interfaces, RESTful controllers, and JSON serialization libraries
- coordinates the execution of domain logic.
domain layer
- code that implements business logic
- define the API to communicate with external parts, like the database
infrastructure layer
- app dependencies required to run the app
- database configuration and Spring configuration.
DDD aggregates
An aggregate is a group of business objects which always need to be consistent. Therefore, we save and update aggregates as a whole inside a transaction.
An aggregate root is a class which works as an entry point to our aggregate.
All business operations should go through the root.
Java JPA and DDD
@Entity, is the same as the Entity in DDD and it has an identity
@Embeddable, is the same as a value object or value type, doesn't have an identity
Repository
A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection.
Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer.
Repositories are classes or components that encapsulate the logic required to access data sources.