The proposed service had a reasonable name, a clear diagram, and enough differences from the rest of the system to justify a boundary. We chose not to deploy it independently.
This was not a rejection of the domain model. It was a decision about when the organization should start paying the operational cost of distribution.
The attractive argument #
The capability had its own workflow and would evolve. A service promised independent releases, scaling, and ownership. Those benefits matter after a team has the pressure that requires them.
Before then, it would add a network failure mode, deployment pipeline, telemetry surface, authorization boundary, data-consistency protocol, and another thing to own during an incident. “Small service” does not mean small operational responsibility.
What we protected instead #
We kept the domain boundary inside the existing deployable unit:
- its own module and vocabulary;
- no direct writes into another domain’s tables;
- an explicit internal interface;
- separate tests around its invariants;
- events defined by business meaning, not table changes.
That preserved the option to extract later without pretending extraction would be free.
The extraction trigger #
“When we scale” is not a trigger. We wrote observable reasons:
- materially different scaling;
- repeated release coupling;
- a durable team ownership boundary;
- measurable value from fault isolation;
- data or compliance rules demanding independent control.
Until one became true, a separate process would have been architecture in advance of evidence.
Every technology choice consumes learning capacity. A small team operating five understandable components can move faster than the same team operating fifteen fashionable ones. The constraint is rarely whether engineers can create another service. It is whether they can explain and recover every interaction at 2 a.m.
Saying no also needs precision. “Keep the monolith” cannot become permission for tangled ownership. The decision worked only because the logical boundary was real and reviewed.
Modularity and distribution are different decisions. Make the first early; earn the second through evidence. The service we did not build let the product learn without making the organization operate a hypothesis as permanent infrastructure.
All Field Notes · Service boundaries · Architecture decisions need expiry dates