In this last lesson we only want to put together valuable information for you, look at it as a last lecture. We are going to check the nex topics:
- Source Code
- Architecture Styles and Patterns Links
- DDD Checklists Created during the course
- References to literature used in the course
Here is the lint to the repository with the code we have created for this course. You will find there, a functional implementation (using SpringBoot 2.0 and H2 database) of the domain example we introduced at the beginning of module 2.
There, we tried to apply the different checklists you are going to find in next sections of this document. So, take a moment to checkout the code and review it. There you will find examples of the different patterns and additionally, you will find examples of how to unit tests objects in domain and application layers.
Here you are going to find a list with interesting links you can check to understand better different architecture styles and patterns:
- Layered Architecture
- Hexagonal Architecture
- SOA
- REST
- CQRS
- Event Driven Patterns
- The Clean Architecture
And here we are putting together the different checklists we shared with you during the course, you can use those checklist to try to apply properly the different tactical design patterns:
First we need to define if ddd is the right approach to use to build the solution:
- Check the complexity of the domain
- Check if you will have availability of domain experts
- Check if the team is mature enough and is well structured
Second step is analyse the domain, the requirements and define an initial Domain Model and an initial Ubiquitous Language:
- Build the Domain Model and the Ubiquitous Language WITH the domain experts
- If the domain is really big and complex, you can use Strategic Design to help you to handle that complexity
- Feel free to use any tool or strategy to define the Domain Model and the Ubiquitous Language
- Domain Model, Ubiquitous Language, and business needs can evolve, so be flexible
Third step is define the solution architecture:
- Ensure that you have selected a proper set of layers, and that those layers have a clear responsibility
- Remember the Dependency Rule and ensure you are applying it
- Also remember that the architecture styles and patterns should be selected to solve a particular need or requirement, never to use the last cool pattern or style
Last step is apply the different building blocks:
- Entities
- Value Objects
- Aggregates
- Domain Events
- Domain Services
- Application Services
- Modules
- Factories
- Repositories
Here is the checklist for entities pattern:
- Ensure you have defined all the entities of your domain.
- Ensure you have defined a proper identity for each entity.
- Ensure you have proper behavior implemented inside the entity. Check it is not anemic.
- Ensure all the business rules related with the entity are implemented inside the entity, or in a domain object.
- Consider to use a Value Object to represent the id of each entity.
- Study and define the proper way to obtain the identity of each entity (User Input, Generated by data store, Generated by other systems or Generated by the application)
- Use expressive names, Intention revealing interfaces, and in general, use the clean code good practices Remember to use the ubiquitous language and express it in the entities!
Here is the checklist for value objects pattern:
- Check that the Value Objects are describing, quantifying or measuring something.
- Check if all entities are really entities or if they can become a Value Object
- Do not define identities for the Value Objects.
- Ensure you are overriding Equals and HashCode using all the properties in the value object.
- Remember to ensure all Value Objects are immutable.
- Ensure all the functionalities are Side-Effect-Free.
- Use expressive names, Intention revealing interfaces, and in general, use the clean code good practices
- Remember to use the ubiquitous language and express it in the value objects!
Here is the checklist for aggregates pattern:
- Remember to try to make the aggregates as small as possible
- Ensure you are protecting integrity of entities inside the aggregate. Only the root aggregate should modify them
- Remember to define proper invariants for your aggregates
- Ensure you are modifying only one aggregate per transaction
- You have the eventual consistency bullet, use it!
- Remember to reference aggregates inside an aggregate by Id
- Remember and apply Dimitri’s Law
- Remember and apply the Tell don Ask Pattern
- Avoid the use of repositories inside the aggregates
- If you see you need to modify two or more aggregates in the same transaction, check your design probably you have an opportunity to make it better
- Ensure you are not using dependency injection to load repositories inside the domain services or aggregates. It is better to use double dispatch pattern.
- Use expressive names, Intention revealing interfaces, and in general, use the clean code good practices
- Remember to use the ubiquitous language and express it in the aggregates!
Here is the checklist for domain events pattern:
- Ensure all domain events are immutable
- Ensure you have a proper name for the event, it should reflect the command that originates it
- Remember to not fill up the domain event with so much data
- Use expressive names, Intention revealing interfaces, and in general, use the clean code good practices
- Remember to use the ubiquitous language and express it in the domain events!
Here is the checklist for services pattern:
- Remember that application services are the natural clients of the domain
- Remember that domain services are part of the domain and they should use the ubiquitous language
- Remember that application services are a thin layer, they should only act as coordinators.
- Ensure you do not have business rules inside application services. If you see this maybe you should create a new domain service.
- Ensure the domain services have business logic.
- Ensure business logic inside domain services cannot be moved to entities.
- Use expressive names, Intention revealing interfaces, and in general, use the clean code good practices
- Remember to use the ubiquitous language and express it in the domain services and application services!
Here is the checklist for modules pattern:
- Check modules names describe some aspect of the Ubiquitous Language
- Ensure all classes inside a module are High Cohesive
- Ensure all classes outside a module are Low Coupled with classes inside the module
- Remember to be flexible and change modules names if needed
Here is the checklist for factories pattern:
- Remember you can use any creational pattern you know
- Ensure you are creating factories only to create complex objects
- Check you do not have factories for objects that are really simple to create
- Use expressive names, Intention revealing interfaces, and in general, use the clean code good practices
- Remember to use the ubiquitous language and express it in the factories!
Here is the checklist for repositories pattern:
- Ensure you have repositories only for the aggregates that really need them.
- Ensure your repository behaves as in memory collection or as persistent database.
- Check that the repositories are used only in application layer or domain services. Avoid to use them inside aggregates.
- Use expressive names, Intention revealing interfaces, and in general, use the clean code good practices
- Remember to use the ubiquitous language and express it in the repositories!
And finally lets include a last checklist, with some extra patterns that are commonly used in the ddd context:
- Double dispatch pattern
- Command Object pattern
- Specification pattern
- Delegation pattern
- Self-delegation pattern
- Event Store
- Event Sourcing