DEV Community

Irwansyah
Irwansyah

Posted on

TaroDomain: This is the way to build scalable and beautiful system

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:

PoEAA

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);
}
Enter fullscreen mode Exit fullscreen mode

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)