The product boundary is a strategy decision.

Architecture follows decision rights

A shared capability is not automatically a platform, and a customer-facing interface is not automatically a product. The meaningful question is who owns the outcome and which changes should be independent.

The boundary should follow durable decision rights, service expectations and the cadence of change—not an organizational chart copied into software.

Expose the real coupling

Hidden coupling appears as synchronized releases, duplicated rules, manual reconciliation and meetings required for ordinary change.

Map these coordination costs before choosing service boundaries. Sometimes the right move is separation; sometimes a stronger shared domain is the simpler system.

• Who can change a rule without permission?
• Which failures must remain isolated?
• Where does state become authoritative?
• What capability has an internal customer?

Sequence toward evidence

A target architecture is a hypothesis. Prove one end-to-end slice that crosses the proposed boundary, measure the hand-offs and adjust before multiplying it.

The best boundary is not the most fashionable. It is the one that reduces the cost of the changes the organization actually needs to make.