Skip to content

Artifact Boundary Refactor

Boundary-refactoring process — instantiates Organization–Artifact Topology Alignment

Redraws the artifact's own internal boundaries — splitting, merging, or moving modules — to match the domain or desired architecture, changing the system rather than the teams.

When the artifact's seams are in the wrong place, one lever is to move the seams directly. Artifact Boundary Refactor redraws the artifact's internal boundaries — splitting an overgrown module, merging two that never should have parted, inverting a dependency — to bring the built structure into line with the domain's intended architecture. Its defining move is that it changes the system, not the org: it is the artifact-side counterpart to the team-side Inverse Conway Design Intervention. It moves code, not people, and it does so as a controlled process so the system keeps running through the change.

Example

A logistics SaaS has one Orders module that has swollen to also handle inventory and shipping, because a single team grew and absorbed all three concerns into one blob. The domain boundary review says these are three distinct bounded contexts. An Artifact Boundary Refactor enumerates the options — a big-bang split versus an incremental strangler-fig extraction behind a stable facade — and picks the incremental route: stand up an Inventory service, route reads and writes through a facade, migrate callers one at a time, then repeat for shipping. When it's done, the module boundaries match the domain, and three teams can own three services cleanly instead of stepping on one another inside a shared blob. The system stayed live the whole way through.

How it works

What distinguishes it from a general "clean-up" is that it targets boundaries and sequences the move to stay safe:

  • Take the target boundary from the domain review — the seam the artifact should have.
  • Enumerate the refactoring move — extract, split, merge, or invert a dependency — since each carries a different risk and payoff.
  • Sequence for safety — facades and incremental migration so the system keeps running, rather than a big-bang cutover, wherever the risk warrants it.
  • Execute on the artifact — it reshapes the system; it does not move teams or measure coordination.

Tuning parameters

  • Move set — extract versus split versus merge versus dependency-inversion. The operation chosen sets the risk and the payoff.
  • Sequencing — big-bang versus strangler-fig incremental. Incremental is safer and slower; big-bang is faster and riskier.
  • Facade strategy — how much compatibility shim to build during migration. More shim means a safer cutover but more throwaway work.
  • Scope per step — how much boundary to move at once. Smaller steps de-risk each change but lengthen the whole effort.
  • Coupling target — how decoupled to aim for. Over-decoupling adds layers of indirection nobody needed.

When it helps, and when it misleads

Its strength is that it fixes the artifact directly and can be done incrementally, so a system in daily use can be reshaped toward its intended architecture without a freeze or a rewrite.

Its failure mode is the archetype's central trap: refactoring the artifact while leaving the organization that produced the seams unchanged. Conway's law quietly re-imposes the old boundaries, and the seams you just removed grow back along the unchanged communication graph. The classic misuse is a heroic "architecture clean-up" rewrite that ignores why the mess formed in the first place. The discipline that guards against it is to pair the artifact refactor with the matching organizational change — an inverse-Conway maneuver or an ownership refactor — so the structure the code is moved into is one the org will actually sustain; otherwise the refactor is temporary.[^strangler]

How it implements the components

Artifact Boundary Refactor fills the artifact-side lever of the archetype — the refactoring moves, and nothing beyond them:

  • architecture_refactoring_option_set — the set of artifact-boundary moves it generates, sequences, and executes to reshape the system toward its target.

That single component is deliberate. It does not touch the team_topology_design_option_set — the org-side lever is Inverse Conway Design Intervention — it does not produce the artifact_topology_map (it changes the topology; Architecture Dependency Graph Review maps it), and it consumes rather than maintains the sociotechnical_mismatch_register, which is the Silo Imprint Audit's.