Encapsulation hides data and decisions that are likely to change behind operations clients can understand and rely on. Rather than letting callers coordinate an object’s fields themselves, make the object protect its own valid state. This localizes future changes and prevents the same rule from being reimplemented across the codebase. section 3.0 section 4.2
Expose the smallest interface that serves clients. Do not reveal mutable internal collections, raw state used only to derive a decision, or setters that permit invalid values. Prefer intent-revealing operations such as addEmployee(), hasAvailableSpots(), or isImportantInfoUpdated() over asking clients to inspect fields and reconstruct rules. section 3.1.3 section 3.3 section 3.4
Keep enrollment rules inside the offering
A client that reads available spots, adds an employee to an exposed set, and decrements a counter can leave the offering invalid. Move that sequence into addEmployee(): reject a full offering, add the employee, and update its count together. Clients then request enrollment without knowing how capacity is represented. section 3.1.3
Listing 3.3 Offering entity with the new addEmployee() method
class Offering {
private int id;
private Training training;
private Calendar date;
private Set<Employee> employees;
private int maximumNumberOfAttendees;
private int availableSpots;
public Offering(Training training, Calendar date,
int maximumNumberOfAttendees) {
// basic constructor
}
public void addEmployee(Employee employee) { #1
if(availableSpots == 0)
throw new OfferingIsFullException();
employees.add(employee);
availableSpots--;
}
public int getAvailableSpots() { #2
return this.availableSpots;
}
}
Compare client-managed enrollment with an operation that keeps the capacity invariant in one place. section 3.1.3
Encapsulate even simple state checks. A method such as hasAvailableSpots() may initially be only availableSpots > 0, but it prevents callers from coupling to that representation. If capacity later depends on another structure or rule, the change stays within the offering instead of becoming shotgun surgery. section 3.3 section 3.3.2
Shield the domain from an SDK
A Bot interface can expose sendPrivateMessage(userId, msg) while one concrete implementation creates the third-party ChatBotV1 and BotMessage objects. SDK types remain confined to that implementation, so an SDK change has a known starting point rather than spreading through domain code. section 6.3.3 section 6.0
Encapsulation is not a demand to hide every fact from developers or to build a perfectly interchangeable abstraction. Hide details from dependent code to limit change impact, but retain knowledge that is operationally important—for example, whether an operation is remote or which infrastructure constraints affect efficient design. Choose the boundary according to the cost and value of change. section 6.0 section 6.1.2
At a larger scale, apply the same rule between modules: a module may use caching or other internal mechanisms without making neighboring modules depend on them. Stable interfaces and limited knowledge allow components to evolve independently. section 4.1.1 section 7.3
