---

TL;DR

In the last post we covered the basic concept of DDD, the aggregate and its root. Before we move on with the non-functional approach, let’s try to define at least one aggregate, that could be used as an example for future posts and code samples.

All entries in this series:

• 1 - back to foundations
• 2 - aggregate sketch
• 3 - first implementation
• 4 - finding events
• 5 - applying events
• 6 - recording aggregate
• 7 - the fully functional end

A payment

For sake of providing an aggregate example let me reuse the payment example I introduced for the service kata purposes. The aggregate boundary is handling a single payment. This includes:

• selecting payment method
• registering an answer from the payment gateway
• storing status

Having this we can easily imagine that the API of this aggregate could be similar to:

As you can see, there are no dummy setters or meaningless primitive properties. We exposed meaningful methods and properties for showing the part of the state we want to show. Additionally, the payment constructor shows all the parameters that are required to issue a payment.

With this example we can move forward and provide more insight into its initial implementation and refactoring it towards more functional design.

---