What Is an Aggregate?
Hearing the word aggregate it is not very clear what that means. To really understand this concept we need to go back to history of software development.
Fowler's Domain Model (PoEAA, 2002)
In Patterns of Enterprise Application Architecture, Fowler cataloged the ways to organize domain logic — the logic that belongs to the business, not to databases or UIs:
| Pattern | Shape | When to use |
|---|---|---|
| Transaction Script | One procedure per operation (procedural) | Simple logic |
| Table Module | One class wrapping a table/record set | Dataset-centric stacks |
| Domain Model | "An object model of the domain that incorporates both behavior and data" | Complex, evolving logic |
| Service Layer | Thin API layer sitting above the above | Application boundary |
Before the Domain Model pattern, business applications used Transaction Scripts:
// Transaction Script — all logic in procedural functions
function placeOrder(customerId, items[]) {
customer = customerGateway.findById(customerId);
validateCustomer(customer);
order = new Order();
order.customerId = customerId;
order.total = 0;
for (item in items) {
product = productGateway.findById(item.productId);
orderLine = new OrderLine();
orderLine.productId = item.productId;
orderLine.quantity = item.quantity;
orderLine.unitPrice = product.price;
orderLine.lineTotal = item.quantity * product.price;
order.total += orderLine.lineTotal;
orderGateway.saveLine(orderLine);
}
orderGateway.save(order);
inventoryGateway.reduceStock(items);
notificationGateway.sendConfirmation(customer.email);
}
Problems:
Business logic scattered across scripts
Duplication: same validation logic repeated in every script
No single place to understand the business rules
Hard to test — logic embedded in database access
Objects are just data bags (DTOs)
Fowler proposed building an object model of the domain where objects encapsulate both behavior and data. Instead of procedures manipulating data, you build an object graph where behavior lives with the data it owns. An Order has OrderLines; a Customer has Addresses; the logic for "what's my total?" lives inside Order, not in some script.
Fowler acknowledged the pattern comes in two flavors: a simple domain model that mirrors the database schema (works with Active Record), and a rich domain model with real behavior (needs Data Mapper). Either way, the core idea is: an interconnected graph of domain objects — and that word "graph" is where the trouble starts.
What Fowler Got Right
| Principle | How |
|---|---|
| Objects encapsulate behavior |
Order.addItem() not orderService.addItem(order, product, qty)
|
| Objects collaborate |
Order references Customer and OrderLine directly |
| Business rules live in the model | Customer.canPlaceOrder() |
| Reduces duplication | Validation logic in one place |
| Testable | Objects can be tested without database |
What Fowler's Domain Model Got Wrong (or Left Unsolved)
Continue to: https://techbro.iamtaro.com/en/minibooks/the-design-and-implementation-of-tarodomain-framework/domain-layer

Top comments (0)