# Transfer ownership of the capability, not a folder

A module owner needs responsibility for its rules, public contract, data and operational behaviour. Source-code location is only one part of that responsibility.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Describe what the module guarantees

List the business operations it exposes and the invariants they preserve. For an order module, this might include eligibility for address changes, version handling and the events produced after a committed update.

Keep the contract understandable to callers. Explain expected rejection outcomes and which internal details they must not depend on.

Document data ownership and known exceptions. A receiving team cannot maintain a rule confidently if another job updates the same tables through an undocumented route.

## Transfer change and incident evidence

Provide representative tests for the public operations, prohibited imports and important races. Include a past or synthetic failure showing how to trace an incorrect business state to the operation that created it.

Link the module's logs and metrics to request or operation identifiers. Operators should be able to find the effect without reading unrelated application internals.

Explain downstream notifications and events. A capability's responsibility extends beyond its database write when other systems rely on the result.

## Rehearse a small rule change

Ask the receiving team to change a synthetic eligibility condition and identify every affected caller and test. The exercise reveals whether the public contract isolates the rule or whether knowledge is scattered across modules.

Then have them diagnose a deliberately bypassed operation. They should know which dependency or runtime check is expected to prevent it and how to repair the path.

Update documentation where the exercise exposes hidden assumptions. Avoid compensating for an unclear contract with a long oral explanation that will be lost after handover.

## Assign the ongoing decisions

Name who reviews new public operations, data-access exceptions and schema changes. Keep the dependency rules in the normal check pipeline and give exceptions explicit owners.

If service extraction is being considered, record the reason and remaining transaction or data dependencies. Do not promise that a neat module can be moved remotely without additional design work.

The handover succeeds when the receiving team can preserve the capability's behaviour, explain its effects and evolve its internals without making every caller understand the same business rules independently.

## Sources

- [Microsoft Learn: common web application architectures](https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures)
- [Martin Fowler: Monolith First](https://martinfowler.com/bliki/MonolithFirst.html)