Ownership Driven Architecture

← Back to concept

Start with ownership

Before choosing a folder or an abstraction, identify three things:

• Owner — the module responsible for a capability
• Responsibility — the behavior and invariants it maintains
• Contract — the public interface other modules use

A training program belongs to training. Identity belongs to the identity domain. A CMS adapter translates a content system's contract; it does not own business behavior.

Boundaries express responsibility

A domain may own its models, API, UI, administration, CMS plugins and tests. Moving its interface into a generic widget must not move ownership of its decisions. Widgets compose capabilities; the application composition root connects them.

Dependencies are justified by real relationships between owners. Directory names alone neither forbid nor justify a dependency. Consumers use a public contract rather than another module's internals.

Make the smallest coherent change

Find an existing solution, understand its consumers and preserve intentional boundaries. An abstraction must reduce coupling, localize responsibility or eliminate meaningful duplication. A change is complete when behavior, types, tests and runtime agree.