Aggregates and Facade pattern

Aggregates in domain driven design are in fact the equivalents of facade design pattern. Let us have a look at facade pattern principle:

Facade Pattern:

Almost all design patterns have a common feature: When you read them for the first time, you do not even notice their application and do not understand how they work! The facade pattern is no exception.

What is “facade” at all?

Suppose I have 3 classes within my code. Class1, Class2 and Class3.


As the shape says, these classes have methods that interact with each other.

For example, when the first class executes “A” method. After that, we want the second class to run method “B” and proceed in the same way.

In one sentence, we want to call several methods from several classes and perform some operations.

We usually do this in the form either inside the controller or inside the class, or wherever needed. From these classes, we create instances or and call their methods.

The Facade Pattern is a class that does the same. That is, we have a class that has variables or fields of Class1 and Class2 and Class3, and invokes their methods. Perhaps a code example is more telling to you:

    public class Class1
        public void MethodA()
            //Do SOmething
    public class Class2
        public void MethodB()
            //Do SOmething
    public class FacadeClass
        private Class1 _class1Field = new Class1();
        private Class2 _class2Field = new Class2();
        public void JobMethod()

As you can see in the code, Class 1 and Class 2 have methods used in the ‘Job Method’ method in the Facade class.
Was not it simple? All design patterns are simple. But the complex issue is to know where to use. If you look a little bit, you’ll surely see examples of using this pattern. Controllers in MVC and Services in Domain Driven Design are all examples of using this pattern.


If you are not familiar with DDD architecture, this paragraph may do any good for you.
Aggregate is a concept used in Domain-based architecture. The bottom line is that there are a number of domain entities. Sometimes these Entities work together to interact. Let us take an example:


As shown in the figure, we deal with 4 Entity: Order – Order Items – VatRate and Customer.
As discussed earlier, Domain Driven Design is a kind of process-based development. Consider how a customer wants to register an order. How is this process done? The customer makes an order and then creates a number of OrderItem and places the order ID in the OrderItem? No In the real world, it’s not like that. In the real world, the customer gives an order and announces the goods he wants.
So the customer does not know what the OrderItem is. The customer only knows the order and the goods. And the procedure is to order a number of items.
Aggregates are in fact a number of classes that work together and interact, and only one is seen from the outside which is called aggregate root! So, in the process of ordering, the client only sees the Order class and does not know the details of the case. Just like a sheet of paper that we either write in or remove a product from.
In fact, the client only deals with the Order class and adds a product by AddItem method or by removing a product by RemoveItem method. In this way, it does not engage in the internal complexity of the relationship between Order and OrderItem and other things.
So the total Order, OrderItem, and VatRate classes together form an Aggregate. Consider Aggregate as an order form filled in and then we deal with this form.


As you can see, Aggregates can best be implemented by the Facade Pattern. Consider that the Order class is a facade and have a OrderItem as a field. Then add the items to the OrderItem via the AddItem method.

In the next article, we will look at the differences between the Order Item and the Order.

Leave a Reply

Your email address will not be published. Required fields are marked *