Class-Level Design

Class cohesion is the degree to which a class's members work together towards one responsibility. In a cohesive class most methods use most of the fields, and every member serves the same purpose, such as Order managing its lines and lifecycle, or a Money record holding a value and its arithmetic. Low cohesion shows up as Utils or Manager names, groups of methods that use disjoint subsets of fields, many unrelated injected dependencies, and a class that changes for unrelated reasons. Metrics such as LCOM quantify this. High cohesion matters because a requirement then maps to one place, and the class is easier to name, understand, test and change safely.

Encapsulation means an object hides its internal state and lets clients change it only through operations that preserve its invariants. It is more than private fields with getters and setters: a public setStatus, or a getter returning the internal mutable list, is still a hole. A well-encapsulated Order keeps its lines private, exposes addLine and pay methods that check the current status, derives its total instead of storing it, and returns List.copyOf(lines) so callers cannot modify internals. As a result, invalid states such as a paid order with no lines cannot be created by any caller, and each rule lives in one place where it cannot drift.

Public setters let any caller put the entity into an invalid state, and they push business rules out of the entity into every caller. With setStatus available, code can move a PAID order back to DRAFT or mark an empty order as paid; with setTotal, the stored total can disagree with the lines. Every service, batch job and controller then has to remember the rules, so they get duplicated, drift apart and are tested separately, which is the anemic domain model. Setters also hide intent: setStatus(CANCELLED) says less than cancel(reason, clock). Replace setters with behaviour methods that validate transitions, and create valid objects through constructors or factories.

Tell, Don't Ask means sending a command to the object that owns the data instead of querying its state and making the decision elsewhere. The ask style reads account.getBalance(), compares it with the amount, checks getStatus() and then calls setBalance() from a service. The tell style calls account.withdraw(amount) and lets Account enforce the balance and frozen-account rules itself, throwing a domain exception when needed. Telling keeps behaviour next to its data, which is Information Expert, keeps invariants in one place and reduces coupling to internal structure. It works hand in hand with the Law of Demeter. Queries are still fine for display and reporting; the rule targets decisions and state changes.

A value object has no identity: it is defined entirely by its attributes, is immutable and is compared by value, so two Money instances of 100 INR are interchangeable. An entity has a stable identity that persists while its attributes change over a lifecycle, so two customers with the same name are still different customers, and equality is by ID. In Java 25, value objects are naturally records with compact constructors for validation, such as Money or Email, while entities are classes with private state changed only through behaviour methods. Prefer value objects wherever identity is not needed: they are thread-safe, easy to test, safe to share and cure primitive obsession.

I use the GRASP heuristics as a sequence of questions. Which data does the behaviour need? Information Expert puts it in the class holding that data. Who creates this object? Creator suggests the aggregate that contains or closely uses it, so Order creates its OrderLines. Does the behaviour span several objects and fit none of them? Make a domain service or policy, a Pure Fabrication such as RefundPolicy. Will it vary? Protected Variations puts it behind an interface with strategies. Who receives the use-case request? An application service acting as Controller. Finally I check Low Coupling and High Cohesion: if an assignment adds many dependencies or unrelated members, I reconsider it.

JPA needs a no-argument constructor and a way to set fields, but not public setters. Use field access, by annotating fields or with @Access(AccessType.FIELD), so Hibernate writes fields directly and the class can expose only behaviour methods. Make the no-arg constructor protected for the provider, and offer a public constructor or static factory that creates a valid entity. Keep collections private, mutate them only through methods such as addLine, and return List.copyOf or an unmodifiable view. Model values as @Embeddable types, which Hibernate 6.2 and later also accept as records, for example Money. Ban public setters with an ArchUnit rule, and watch lazy loading inside domain methods.

The same principles apply at every scale; only the boundary gets larger. A cohesive class owns one responsibility; a well-designed service owns one business capability and changes for one reason. Encapsulation becomes data ownership: a service hides its database behind its API just as a class hides its fields behind methods, and no other service reads its tables. Intention-revealing methods become small APIs with commands like PlaceOrder rather than generic CRUD endpoints. Collaboration rules such as Tell, Don't Ask and few collaborators become avoiding chatty calls and long synchronous chains, often by using events. Teams that design self-protecting classes tend to build self-protecting modules and services.