Why Object Modeling Beats Data Modeling: A Deep Dive into OOP, Composition, and Aggregation

Object‑Oriented

Object‑oriented is a method of understanding and abstracting the world. An object is an abstraction of a thing , which consists of things (events) and objects (entities). Understanding objects means abstracting the attributes and behaviors of things.

The core of object‑oriented design is the combination of attributes and methods into objects. When modeling, you should consider whether you need both attributes and methods, only attributes, or only methods.

Attributes and Operations

The essence of OOP is that an object is composed of attributes and methods. You should think of objects as a combination of these two parts; a pure‑attribute or pure‑method object is usually undesirable.

When do you need an object that combines attributes and methods?

When do you need an object that contains only attributes?

When do you need an object that contains only methods?

Object Modeling

In database systems only the entity (the "object" part) is considered, so they model only attributes. In application systems you must decide whether to model a combination of attributes and methods, only attributes, or only methods.

Because a database table stores only attributes, it often yields an incomplete model compared with a full object model.

Example: a simple financial account.

Attributes: id, balance, status.

Operations: open, close, credit, debit.

create table account (
    id integer,
    balance integer,
    status integer
);

Java data‑model class:

@Getter
@Setter
public class Account {
    private int id;
    private int balance;
    private AccountStatus status;
}

Object‑model interface:

public interface Account {
    int getId();
    int getBalance();
    AccountStatus getStatus();
    void open();
    void close();
    void credit(int amount);
    void debit(int amount);
}

Implementation of the interface:

@Getter
public class Account {
    private int id;
    private int balance;
    private AccountStatus status;

    public void open() { this.status = AccountStatus.OPENED; }
    public void close() { this.status = AccountStatus.CLOSED; }
    public void credit(int amount) { this.balance += amount; }
    public void debit(int amount) { this.balance -= amount; }
}

Account Credit

Using the data model, business logic resides in a service layer (AccountService), which coordinates operations.

Java implementation of the service:

public class AccountService {
    private final AccountRepository accountRepository;
    public AccountService(AccountRepository accountRepository) {
        this.accountRepository = accountRepository;
    }
    public Account creditAccount(int accountId, int amount) {
        var account = this.accountRepository.findById(accountId)
                .orElseThrow(() -> new AccountException("The Account was not found"));
        if (AccountStatus.OPENED != account.getStatus()) {
            throw new AccountException("The Account is not open");
        }
        account.setBalance(account.getBalance() + amount);
        return this.accountRepository.save(account);
    }
}

When using an object‑model mindset, the service becomes an application service that merely coordinates calls:

public class AccountService {
    private final AccountRepository accountRepository;
    public AccountService(AccountRepository accountRepository) {
        this.accountRepository = accountRepository;
    }
    public Account creditAccount(int accountId, int amount) {
        var account = this.accountRepository.findById(accountId)
                .orElseThrow(() -> new AccountException("The Account was not found"));
        account.debit(amount);
        return this.accountRepository.save(account);
    }
}

This service contains no business logic; it only orchestrates the workflow and is therefore an application service .

Composition and Aggregation

In software design, composition and aggregation describe stronger whole‑part relationships than simple associations. Composition implies that the part cannot exist without the whole (e.g., a car and its wheels), while aggregation allows the part to exist independently and be replaceable.

Example of composition: a person (whole) with mouth, esophagus, stomach, and intestine (parts). The parts are created and destroyed together with the person.

Example of aggregation: a car and its tires; tires can be replaced without destroying the car.

Code illustrating composition:

// Mouth
public class Mouth {
    public Object chew(Object food) { return food; }
}
// Esophagus
public class Esophagus {
    public Object transfer(Object paste) { return paste; }
}
// Stomach
public class Stomach {
    public Object fill(Object paste) { return paste; }
}
// Intestine
public class Intestine {
    public void absorb(Object chyme) { /* absorbing... */ }
}
public class Person {
    private final Mouth mouth = new Mouth();
    private final Esophagus esophagus = new Esophagus();
    private final Stomach stomach = new Stomach();
    private final Intestine intestine = new Intestine();
    public void eat(Object food) {
        var paste = mouth.chew(food);
        paste = esophagus.transfer(paste);
        var chyme = stomach.fill(paste);
        intestine.absorb(chyme);
    }
}
public class PersonTests {
    public static void main(String[] args) {
        new Person().eat("chips");
    }
}

Open‑Source E‑Commerce

Mallfoundry is a fully open‑source multi‑tenant e‑commerce platform built with Spring Boot. It follows domain‑driven design, modular interfaces, and object‑oriented principles.

Summary

Object modeling, contrasted with data modeling, demonstrates the need for an object‑oriented mindset.

The account example shows how to apply object modeling in a business scenario.

Composition and aggregation are explained to clarify whole‑part relationships in object‑oriented design.