Learning · Software Engineering Manifesto
Own clear boundaries
Every capability has one owner for behavior and data — independence starts with the cut, not with the deployable count.
Principle
A service (or module) owns a business capability end to end: its rules, its data, and the interfaces others use. Technology layers are not boundaries.
Therefore we practice
- Draw boundaries from capabilities and invariants, not from frameworks or folders
- One writer for a given piece of authoritative state; others request or subscribe
- Prefer autonomy of change: can we deploy this without a lockstep release of three other systems?
- Document the owner of each public API and event type
- When two things always change together and share invariants, keep them together
Smells
- Shared database tables updated by multiple teams “for convenience”
- “Utils” or “common” services that own everyone’s logic
- Distributed monolith: many deployables, one release train, one blast radius
- Boundaries explained only as “the Java package” or “the repo name”