Designing a Small Object Model

Start from the language the domain uses, not from the database schema or the API payload. Write down the nouns that appear in the requirements and in what people say about the business. Then ask each noun two questions: does it have identity, meaning that two instances with the same contents are still distinguishable, and does it have behaviour that belongs to it alone?

Identity and behaviour together identify the entities worth a class. A product with a stock-keeping unit, a name and a price that the business rules about is an entity. A total computed from a basket is a value, and it belongs on whatever owns the basket rather than being a class of its own.

The second step is to decide who owns each piece of state. Every piece of data should have exactly one owner, and the owner is the class whose behaviour depends on it. That rule resolves most arguments about where a field belongs, and it gives you a natural boundary for each class.

The third step is to write the interactions before the fields. Describe the scenarios the system has to support, in terms of which object asks which other object to do what. The collaborations that show up repeatedly are the ones worth a named interface, and the objects that participate in none of them are probably not needed.

Finally, keep the model small and expect to change it. The first version of an object model is a hypothesis about the domain, and the cheapest time to discover that a hypothesis is wrong is while the code is still small. Model what you need for the next requirement, not everything you imagine the domain might eventually contain.

The model has two classes, and the split is deliberate. A product owns what a product is, which is its name and its price. A shop owns what a shop has, which is the stock levels, and it owns the operations over that stock: recording a quantity, counting the units and valuing the inventory.

public class Main {
    public static void main(String[] args) {
        Shop shop = new Shop();
        shop.stock(new Product("Mug", 9.0), 4);
        shop.stock(new Product("Plate", 12.0), 2);
        System.out.println(shop.stockCount());
        System.out.println(shop.stockValue());
    }
}

class Product {
    private final String name;
    private final double price;
    Product(String name, double price) { this.name = name; this.price = price; }
    String name() { return name; }
    double price() { return price; }
}

class Shop {
    private final java.util.Map<Product, Integer> stock = new java.util.LinkedHashMap<>();
    void stock(Product p, int count) { stock.put(p, count); }
    int stockCount() {
        int total = 0;
        for (int c : stock.values()) { total += c; }
        return total;
    }
    double stockValue() {
        double total = 0;
        for (java.util.Map.Entry<Product, Integer> e : stock.entrySet()) {
            total += e.getKey().price() * e.getValue();
        }
        return total;
    }
}

The output shows the two responsibilities in action. The shop reports six units in stock and an inventory value of 60.0, which is four mugs at 9.0 plus two plates at 12.0. The arithmetic lives in the shop because it is a question about the shop's stock, not about a single product.

The boundary is the interesting part. The quantity is not stored on the product, because the same product might be stocked in several shops at different levels. Storing it on the product would give the product two conflicting answers. Instead the shop keeps a map from product to quantity, which is exactly the aggregation relationship, and the product stays a small value object that other things can hold.

Two design details are worth naming for an interview. The product fields are final, so a product cannot change its price after it is in the stock map, which keeps the map a reliable key. And the shop exposes operations rather than the map itself, so a caller cannot bypass the shop's rules by editing the stock directly.

The first mistake is designing the database tables instead of the domain. If your class names are pluralised column names and your methods mirror selects and inserts, you have built a wrapper around storage rather than a model of the business, and every business rule ends up in the service layer.

The second is the anemic model. Classes that hold fields and nothing else, with all the behaviour in a service that operates on them. The symptom is that the service needs to reach into the objects, so the objects cannot enforce their own rules and every invariant has to be checked in every service.

The third is putting behaviour in the wrong place. A rule about which discounts apply belongs to the basket or the line item, not to a checkout service that happens to know about both. The test is whether the behaviour can be stated without naming a caller.

The fourth is modelling everything. A class for every table, including ones nobody uses, means a change to the schema ripples into the model. And the fifth is designing for the future. Speculative classes and speculative fields become liabilities the moment the real requirement differs from the guess.

The habit that prevents most of these is to start with the scenarios. Write the interactions the system has to support, then let the classes fall out of who participates in those interactions. That keeps the model small and every class earned.