Aggregates are guards for business principles in domain implementation. They merge several contexts into one, transparent object which unifies the interface for aggregated stuff. For example we can have many entities and value objects nested in aggregate. Our security guy will provide a mechanism for checking aggregated data consistency and integrity. Using policies and specifications (which I described in the previous chapter of the series Domain Driven Design: domain building blocks) we can ensure immutability of business assumptions.  

From previous chapters we already know strategic concepts of Domain Driven Design. We have knowledge on how to design our system and now we need to know how to implement designed solutions. In the DDD world we can distinguish many building blocks - components which are useful in a part of technical Domain Driven Design.   

In the previous chapter of the Domain-Driven Design series, we talked about the basic concepts of DDD. As I mentioned last time: one of the most difficult parts of the approach is to properly identify and discover domains. With the basic knowledge of DDD, we can jump into this topic and try to understand how to properly identify domains.

Domain Driven Design is an approach with many applications which is often used in the process of domain design, communication organization, implementation of business assumptions or support in project management. If you create complex systems and would like to learn how to do it better, then this article is for you.