DEV Community: Bob Palermo

The First Seam

Bob Palermo — Thu, 29 Oct 2026 13:53:56 +0000

Identifying Fulfillment as a boundary is only the first step. Now ZibiWorks needs a safe place to separate it.

This article is part of ZibiWorks, an ongoing fictional modernization case study. The ZibiWorks site is the canonical home of the series, with the full company context, starting architecture, and related installments. Explore the full series at ZibiWorks.

In Installment 03: Rewrite vs. Evolve, ZibiWorks chose evolutionary modernization over a rewrite. In Installment 04: Boundaries and Meaning, we identified the business boundaries that should guide that evolution.

Now we need somewhere to act on those decisions.

Fulfillment is still embedded in the monolith, tightly coupled to ordering and inventory. We know what should be separated. The question is where and how to begin separating it safely.

That place is a seam.

From boundary to seam

The business boundary establishes what must be separated. The technical seam establishes where and how.

Installment 04 did the first half, establishing Fulfillment as a real business capability with its own responsibilities, distinct from Inventory and Order Management. This installment does the second: finding a place where that boundary can be acted on in code without forcing everything around it to change at once.

A seam is a controlled point of substitution, where one implementation can replace another without requiring changes to the consuming business logic.

In Installment 03, ZibiWorks chose to evolve the monolith incrementally rather than replace it wholesale. That approach follows the Strangler Fig pattern: gradually moving responsibilities out of the monolith while the existing application continues to operate.

But to redirect a responsibility, we first need a place where that redirection can happen. Fulfillment doesn't have one. Its logic is still tangled into Ordering, and introducing that substitution point is the work of this installment.

The challenge is that not every technically substitutable point is a good place to make the cut.

Where Fulfillment lives today

Right now, ordering reaches straight past the boundaries Installment 04 identified. When an order is submitted, the same code path reserves inventory and creates the shipment request itself, inline:

public sealed class OrderService
{
    private readonly InventoryRepository _inventory;
    private readonly ShipmentRepository _shipments;

    public async Task SubmitOrderAsync(Order order)
    {
        // ... order validation, pricing, persistence ...

        // Fulfillment, done inline:
        await _inventory.ReserveAsync(order);
        await _shipments.CreateFulfillmentRequestAsync(order);

        // ... confirmation, events, the rest of ordering ...
    }
}

OrderService does not just ask for fulfillment to happen. It knows how fulfillment happens: that an inventory reservation comes first, then a shipment request, and in that order. Those two calls do not even belong to the same context. Reserving stock is Inventory's responsibility; arranging a shipment is work Fulfillment coordinates. Ordering reaches into both directly. There is no seam here, and there is no single place to substitute a new Fulfillment without editing ordering itself. That coupling is the thing standing between ZibiWorks and its first cut.

Not every cut is a good seam

There are several places ZibiWorks could technically insert a substitution point around this code. They are not equally useful, and the differences are the whole architectural question.

1. Repository-level substitution

Put interfaces in front of InventoryRepository and ShipmentRepository. The calls are now swappable, but ordering still orchestrates fulfillment step by step and still reaches into Inventory itself. The seam exposes Fulfillment's mechanics and preserves the existing coupling. We have made the wrong thing replaceable.

2. Legacy-shaped facade

Move the existing logic behind a single facade, but expose a contract that mirrors its internal steps: ReserveInventory then CreateShipment. Ordering no longer calls the repositories directly, but it still knows how fulfillment works and in what sequence. The code has moved; the coupling has not. Replacing the legacy implementation would still mean preserving that sequence or changing the callers.

3. Business-intent contract

Expose what ordering actually needs: RequestFulfillment. Ordering states its intent and says nothing about how inventory or shipment are handled. The contract describes the capability, so any implementation, legacy or extracted, is free to satisfy it differently.

The difference between the second and third is not the facade; a facade can express intent perfectly well. The difference is what the contract is shaped around. A legacy-shaped contract describes the steps the old code takes. A business-intent contract describes what ordering wants to be true. Only the latter gives Fulfillment room to change behind it, which is the point of drawing the boundary in the first place.

A good seam expresses business intent, not legacy implementation mechanics.

An interface can enforce a technical separation, but it doesn't establish where the business boundary belongs. That decision comes from understanding the responsibilities on either side. The seam is how ZibiWorks acts on a boundary it has already reasoned about, so the contract has to reflect that boundary rather than the legacy call sequence.

What makes a seam worth cutting

Business intent is the primary test, but a few other principles decide whether a candidate seam is worth committing to.

Criterion	What to look for
Business alignment	Represents a meaningful business capability, not an incidental grouping of code.
Narrow surface	Few callers need to understand or participate in the transition.
Stable contract	Remains meaningful while implementations change.
Substitutability	One implementation can replace another without changing consuming business logic.
Model independence	The contract carries only the data the capability needs without exposing the caller's domain model.

RequestFulfillment satisfies these criteria. The repository-level alternatives may be technically substitutable, but they preserve the wrong responsibilities and dependencies. The difference isn't whether an interface exists. It's whether that interface establishes a useful boundary.

Creating the seam

With the seam identified, the next decision is what crosses it. Ordering needs to request fulfillment, but Fulfillment shouldn't need to understand Ordering's entire domain model.

That means defining a contract around the business intent and a request containing only the information Fulfillment needs. Once those decisions are made, dependency injection (DI) provides the mechanism for selecting the implementation.

Ordering depends on a contract that states intent, and nothing more. Note what it does not pass: the Order itself. It hands Fulfillment a request carrying only what Fulfillment needs.

public interface IFulfillmentService
{
    Task RequestFulfillmentAsync(FulfillmentRequest request);
}

public sealed class OrderService
{
    private readonly IFulfillmentService _fulfillment;

    public OrderService(IFulfillmentService fulfillment) =>
        _fulfillment = fulfillment;

    public async Task SubmitOrderAsync(Order order)
    {
        // ... order responsibilities ...
        var request = FulfillmentRequest.From(order);
        await _fulfillment.RequestFulfillmentAsync(request);
        // ... remaining order responsibilities ...
    }
}

That request is deliberately small: the items and quantities to fulfill, a destination, an order reference. Not the Order aggregate with its pricing, payment, and customer detail.

A seam can hide implementation mechanics and still leak the caller's domain model. A good contract carries only what the receiving capability needs.

Passing Order across the seam would tie Fulfillment to Ordering's model, so a change to how orders are shaped could ripple into Fulfillment. The seam should decouple both the implementation behavior and the shape of the data that crosses it.

The contract has two implementations, and they are alternatives, not a chain. Today, dependency injection supplies the legacy one; later it can supply the extracted one. Only one is active for a given configuration.

// Today: the existing orchestration, lifted behind the
// seam, still running inside the monolith. Fulfillment
// coordinates the existing process. Inventory retains its
// stock reservation rules, and the existing shipping
// integration remains unchanged. Domain ownership and
// integration boundaries are not redesigned in this step.
public sealed class LegacyFulfillmentService
    : IFulfillmentService
{
    private readonly InventoryRepository _inventory;
    private readonly ShipmentRepository _shipments;
    private readonly LegacyOrderAdapter _adapter;

    public LegacyFulfillmentService(
        InventoryRepository inventory,
        ShipmentRepository shipments,
        LegacyOrderAdapter adapter)
    {
        _inventory = inventory;
        _shipments = shipments;
        _adapter = adapter;
    }

    public async Task RequestFulfillmentAsync(
        FulfillmentRequest request)
    {
        // Load the Order the legacy repositories still
        // require, by order reference. The request carries
        // fulfillment intent, not Ordering's whole
        // aggregate, so the adapter resolves the persisted
        // Order here.
        var legacyOrder =
            await _adapter.LoadLegacyOrderAsync(request);

        await _inventory.ReserveAsync(legacyOrder);
        await _shipments.CreateFulfillmentRequestAsync(
            legacyOrder);
    }
}

// Later: a separately deployed Fulfillment service,
// satisfying the same contract from across a network
// boundary. It owns the Fulfillment responsibilities and
// collaborates with Inventory through a defined contract.
public sealed class FulfillmentApiClient
    : IFulfillmentService
{
    // POST /fulfillment/requests
}

The original repositories expect an Order, but the new contract accepts a smaller FulfillmentRequest. The legacy adapter uses the order reference to retrieve the original Order and supply the input those repositories still require. That compatibility logic stays behind the seam and disappears when the legacy implementation is retired.

The legacy implementation adapts to the new contract, not the other way around.

A clean boundary doesn't require the legacy implementation to be clean. It requires the legacy complexity to remain behind the boundary.

Both implementations must honor the same business contract, including what it means for a fulfillment request to be accepted, even as the execution model changes. During this initial refactoring the underlying business behavior is intended to stay the same: the legacy adapter runs the same inventory and shipment operations against the same data stores, now reached through the new contract.

Which implementation is live is decided in one place, the composition root, by registering the contract against one or the other. Ordering never learns which it got.

At runtime, Ordering depends on the contract and reaches whichever implementation is wired in: the legacy one today, an extracted service later. The composition root is configuration, not a step in the request, it selects which implementation satisfies the contract. The dotted paths are the future state, not calls the legacy implementation makes.

What the seam settles, and what it doesn't

The seam gives ZibiWorks a controlled way to change how Fulfillment is implemented without changing Ordering. That is meaningful progress, but it is important to distinguish what has been accomplished from what remains unresolved.

Concern	Status	Why
Business boundary	Established	Fulfillment was identified as a distinct business capability in Installment 04: Boundaries and Meaning.
Technical seam	Established	`IFulfillmentService` gives Ordering one stable contract through which to request fulfillment.
Implementation substitution	Enabled	The composition root can select the legacy implementation or a future extracted one without changing Ordering.
Business responsibility ownership	Partially settled	Fulfillment's boundary is established, but responsibilities involving Inventory and shipping still need refinement.
Service extraction	Not yet	`LegacyFulfillmentService` still executes inside the monolith.
Data ownership	Not yet	The shared database is unchanged. An interface does not establish data ownership.
Distributed communication and consistency	Not yet	Timeouts, retries, idempotency, partial failures, and cross-service coordination remain migration concerns.
Cutover and rollback	Partially enabled	Switching implementations is localized, but reversing distributed side effects or data changes takes more than switching a DI registration.

The seam makes the application-level substitution decision reversible. It does not automatically make every consequence of extraction reversible. While LegacyFulfillmentService runs in the monolith against the same tables, pointing Ordering back at it is a single change. Once an extracted service starts writing its own data or causing side effects across a network, rollback stops being a dependency-injection choice and becomes a broader architectural problem of data and consistency. That belongs to later installments of Part III, not here.

Temporary by design

LegacyFulfillmentService and the transition wiring are migration scaffolding. They exist to make the change incremental, not because they belong in the final architecture. As discussed in Installment 03: Rewrite vs. Evolve, temporary code is not waste when it makes a difficult transition safer.

Where this leaves ZibiWorks

ZibiWorks now has a controlled place to begin extracting Fulfillment. Ordering expresses what it needs, the legacy implementation continues to serve that request, and the path to a replacement no longer runs through Ordering's business logic.

But the seam is only a technical mechanism. It doesn't decide which responsibilities belong to Fulfillment or which should remain elsewhere.

Creating a technical seam does not determine ownership. The business boundary does, and the seam only gives ZibiWorks somewhere to act on it.

Next: Domain or Utility?

Inventory reservation illustrates why that distinction matters. Fulfillment needs inventory reserved, but as we established in Installment 04: Boundaries and Meaning, Inventory owns the rules governing stock. Fulfillment requests a reservation; it doesn't own Inventory's business logic.

Shipping presents a different question. Fulfillment needs to arrange delivery through Handle With Care, and potentially other carriers in the future. But does integrating with a carrier belong inside Fulfillment, in a separate business domain, or behind a shared technical capability?

These aren't simply decisions about where to put code. They are decisions about business responsibility, ownership, and reuse. And that's where another common architectural mistake appears: not everything reusable should become a shared service, and not every external integration deserves its own bounded context.

The next installment explores how to distinguish business domains from supporting utilities, and why getting that distinction wrong can recreate the coupling we're trying to remove.

ZibiWorks is fictional. The ideas and opinions expressed throughout the series are my own and do not represent the views, positions, or practices of my employer.

Boundaries and Meaning

Bob Palermo — Wed, 21 Oct 2026 16:29:43 +0000

Before separating the software, ZibiWorks needs to understand the business boundaries hidden inside its monolith.

We've chosen Fulfillment. But what is it?

ZibiWorks decided to evolve its platform rather than replace it, and picked
Fulfillment as the first target. The obvious next step is to find the Fulfillment
code and pull it out. But before doing that, the team needs to establish what
actually belongs to Fulfillment.

In the current application, ordering, inventory, and fulfillment are tightly
woven together. They share classes, business logic, and the same Order model.
Extract everything that touches that model and the move drags along far more than
Fulfillment; extract too little and the new service still depends on the monolith
for decisions it should own. Before moving any code, the team has to understand
how the business actually works.

Start with the business, not the database

That understanding comes from the people who run the work, not from reading the
schema. Each business function that participates in an order has its own
perspective on it. ZibiWorks brings together subject matter experts from Order
Management, Inventory, and Fulfillment, along with business analysts and software
architects. Rather than starting with
the existing application, the group walks through several business scenarios: a
straightforward order, a return, a cancellation already in progress, and the
example below. The goal isn't to document every workflow, but to uncover where
responsibilities, decision ownership, and the meaning of common terms begin to
diverge.

One of those scenarios exposes the problem particularly well. A customer orders
three of the same product. Only two are on hand; the third is out of stock. That
single situation pulls the groups apart. Inventory can reserve two units and has to decide what the third
reservation even means with no stock behind it. Fulfillment can pick and pack the
two available units now, but only if a partial shipment is allowed. Order
Management owns that call, because splitting one order into two deliveries touches
pricing and the customer commitment. Nobody can answer alone, and each is
answering a different part of the question.

That disagreement is the useful part. The same word starts to mean different
things depending on who is saying it. Take available:

Business perspective	What "available" means
Order Management	The customer is allowed to buy it; it is sellable right now
Inventory	Physical stock is on hand and not already reserved
Fulfillment	The item is somewhere it can actually be picked and packed

None of these is sloppy or wrong. A product can be available to sell while there
is no stock to reserve, which is precisely how a backorder happens. The word is
only unambiguous inside one context.

It is tempting to treat these differences as a data problem and add more statuses
or flags to the shared Order model. But that doesn't resolve the underlying issue.
The business functions have different rules and make different decisions. More
fields won't establish who owns those decisions.

Candidate boundaries

Domain-Driven Design gives the team a useful concept: the bounded context. A
bounded context defines where a particular business model, its rules, and its
language have consistent meaning. That is exactly why available can carry three
different meanings at once without any of them being wrong: each belongs to a
different context.

The differences in language aren't just vocabulary problems. They point to
different rules, responsibilities, and decisions. So the team draws its candidate
boundaries from those rules, language, and decision ownership, not by copying the
org chart into the architecture.

Key Concept

Ubiquitous language needs to be consistent within a bounded context, not across the entire business.

The conversations point to three candidate bounded contexts: Order Management,
Inventory, and Fulfillment.

Order Management

The customer's commercial transaction
Orders, order lines, pricing, commitments
Cancellations and the order lifecycle

Inventory

Availability and commitment of stock
SKUs, on-hand quantities, reservations
Replenishment and warehouse locations

Fulfillment

The operational work to satisfy an order
Pick lists, packing, shipment preparation
Handoff, dispatch, exceptions

A fourth candidate shows up as the group follows a package out the door. Getting
items picked and packed is Fulfillment's work. Moving the parcel after that,
transportation itself, is a different kind of concern with different experts and
a different model.

Fulfillment

Picking and packing items
Preparing shipments
Managing fulfillment work and handoff

Shipping

Carrier selection and transportation
Route optimization and delivery exceptions
Fleet maintenance, where applicable
Delivery tracking in transit

ZibiWorks does not run trucks. It hands parcels to Handle With Care, an
external carrier, so most of that right-hand list is the carrier's business, not
ZibiWorks'. The open question is whether ZibiWorks has enough Shipping rules and
decisions of its own to justify a separate bounded context, or whether Shipping is
primarily an integration concern. How that integration is implemented is a
separate architectural decision we'll address later. For now, Shipping remains a
candidate worth investigating, and the focus stays on Fulfillment.

What belongs to Fulfillment

Working from the conversations rather than the schema, the team sorts
responsibilities by who owns each decision.

Responsibility	Business owner
Capture and manage customer orders	Order Management
Handle commercial cancellations	Order Management
Maintain stock availability	Inventory
Reserve and allocate stock	Inventory
Decide how accepted order lines are fulfilled	Fulfillment
Manage picking and packing	Fulfillment
Prepare shipments and hand off to the carrier	Fulfillment
Report fulfillment progress	Fulfillment

Naming an owner for each decision does not remove the need to collaborate.
Cancellation is the clearest case. Order Management owns the decision, but it
cannot make it alone: whether a cancellation is even possible depends on how far
the physical work has gone, and that fact belongs to Fulfillment. Neither context
takes over the other's rules, and the decision still needs both.

Order Management owns the decision and the commercial rules; Fulfillment owns the operational facts. The diagram is conceptual: it says who decides what, not how the two contexts talk to each other.

That is the shape of a real boundary: collaboration without shared ownership.

One order, several lifecycles

The product owner asks the fair question: if Fulfillment separates from Order
Management and Inventory, how does a customer check their order? They do not want
three status screens.

A coherent customer view does not require one context to own the whole order.
Take the three-item order: Order Management knows it was accepted, Inventory knows
two units are reserved and one is not, Fulfillment knows the available items are
packed and on their way. The customer-facing view can present information from
all three contexts without becoming authoritative for their underlying business
state. Whether ZibiWorks assembles that information on demand or maintains a
separate read model is a decision for a later installment. The read view is
derived; the owning contexts remain the source of truth.

A context owns its data. That doesn't mean it's the only context that needs access to it.

Now look at the monolith

The business analysis produced a clean map of responsibilities. The next step is
to hold it up against the existing application and see how much of it the code and
data actually reflect. The answer, in the legacy Orders table, is not much. A
single row has accumulated fields from several parts of the business at once.

The same row holds Order Management, Inventory, and Fulfillment fields, with the two shipping fields still unassigned. The business drew three clean boundaries; the table drew none.

The shape made sense once. ZibiWorks shipped from one warehouse, an order was one
shipment, and the path from placed to shipped was close to linear, so putting it
all on the order record was the simplest thing that worked. Then the business
changed. More warehouses broke the single WarehouseId. Partial shipments turned
one order into several deliveries. Backorders, specialized carriers, and more
involved inventory commitments each needed somewhere to live, and the fastest
place was another column on a table everything already understood. No single one
of those decisions was wrong; added up, they left the Order model owning work
from three different parts of the business, and a fourth knocking at the door.

The database reflects years of implementation decisions, not necessarily where the business boundaries belong.

Deciding what moves

The business boundaries turn the extraction choice into something the team can
defend rather than guess at.

Candidate bounded context	Decision	Reason
Fulfillment	Extract	The scalability and resilience pressures that started the modernization
Order Management	Remain	Commercial workflows are stable and were never the problem
Inventory	Remain	Reach extends well beyond this effort; extracting it now blows up the scope
Shipping	Investigate	Still an open question, not an extraction commitment

Picking Fulfillment is the easy part. The risk is moving the code without
achieving the separation. Fulfillment still needs stock reserved by Inventory and
order and cancellation decisions from Order Management, and today it reaches all
of that through the shared Order row. Give it its own service but leave those
dependencies in place, and Fulfillment spends its life calling back into the
monolith: slower than the method calls it replaced, still hostage to legacy data
and release schedules, and buying little of the scalability and resilience that
justified the move. Moving the code into its own service doesn't mean you've
removed the coupling. The business decision is settled; making the separation
real is the part still to work out.

The boundary before the seam

ZibiWorks now understands its business boundaries, and it knows the
implementation does not honor them. That gap is the real result of this
installment. Knowing what to separate tells ZibiWorks what Fulfillment must stop
sharing, but not where the running system can actually be cut or how Fulfillment
gets what it needs once it is. That is the next problem.

Key Takeaway

The business boundary establishes what must be separated. The technical seam establishes where and how.

ZibiWorks is fictional. The ideas and opinions expressed throughout the series are my own and do not represent the views, positions, or practices of my employer.

Rewrite vs. Evolve

Bob Palermo — Wed, 14 Oct 2026 12:34:17 +0000

The platform has to change. The question is how: replace it with a clean-sheet build, or evolve the existing system toward the target.

The infrastructure question is settled. ZibiWorks chose to move before
modernizing the application, but that decision left the monolith, the shared
database, and the tangled domains intact. With the migration path established,
attention turns to how the application itself should change.

The problem forcing the question

A specific business capability is under pressure: Order Fulfillment.

As ZibiWorks has grown, seasonal demand has grown with it, and Fulfillment
needs to scale more independently than it can today. Because Fulfillment is
embedded in the monolith, adding capacity for it means scaling far more of the
application than necessary, and problems or deployments in unrelated areas can
disrupt fulfillment processing. As order volume climbs, its availability and
resiliency matter more every quarter, and leadership wants this materially
improved before the next major peak season.

ZibiWorks is not modernizing for cleanliness. It has a business capability
that has to get better on a specific timeline, and that deadline is the single
most important criterion weighing on the decision.

Before comparing the two paths, one thing is worth settling: this is a decision
about how ZibiWorks travels, not where it is going. Whichever path it takes,
good domain analysis should land on substantially the same business
capabilities, bounded contexts, ownership, and data responsibilities. An
evolutionary path may surface new information along the way, so the final
implementation can differ in detail, but the migration mechanism should not
dictate the target decomposition. The destination is not what is in question
here.

Two credible options

Both are credible. Neither is foolish.

Option A: Rewrite

Design and build the new platform alongside the existing system
Migrate the business onto it
Retire the old system

Option B: Evolve

Create seams in the existing platform
Move capabilities into new bounded contexts over time
Retire legacy implementations as confidence grows

A clean rewrite is genuinely appealing: clean boundaries from day one, a modern
architecture without legacy compromises during construction, freedom to rethink
persistence and integration, and far less transitional scaffolding cluttering
the codebase. Building straight toward the desired end state is a real
advantage, and it deserves a serious evaluation rather than a reflexive "big
rewrites fail."

Evolution has its own strengths and its own real costs. The two differ on three
things that matter here: where the complexity lands, when the business sees
value, and how data moves.

Where the complexity lands

Neither approach avoids complexity; they place it differently in time. Both
involve substantial construction work. What differs is where the migration,
coexistence, validation, and cutover complexity falls.

Dimension	Evolution	Rewrite
Complexity	Migration complexity distributed throughout the transition: temporary adapters, compatibility layers, and synchronization.	Cleaner construction path, but migration and cutover complexity concentrated near completion.
Delivery of value	Fulfillment can improve independently while the rest of the platform evolves.	Fulfillment improvements depend on enough of the replacement platform being ready.
Data migration	Incremental, domain by domain. Ownership and validation move in smaller steps.	Larger, coordinated migration and reconciliation near cutover.

Evolution distributes migration complexity across the journey. A rewrite concentrates much of it near the destination.

Can a rewrite meet the deadline?

On construction alone, a rewrite might. The deciding question is not whether
ZibiWorks could build a replacement in time, but what it would take to put one
safely into production before the busiest period of the year.

A full-platform replacement couples the Fulfillment deadline to the readiness of
the entire new platform. Before peak season, ZibiWorks would have to validate
not just Fulfillment but every capability on it, resolve defects in capabilities
that are not driving the deadline, and complete data migration, reconciliation,
and a production cutover, then stabilize an entirely new platform right before
its highest-demand weeks.

Those pressures have nothing to do with Fulfillment. It could be
production-ready while defects in Customer Management or Billing hold up the
cutover, with QA and release capacity consumed by unrelated problems. Even a
rewrite delivered on time would send ZibiWorks into peak season on a platform
with little production history. The risk is not simply missing the date; it is
introducing broad operational uncertainty across the whole system at the exact
moment Fulfillment needs to be more reliable.

This is not an argument that rewrites fail. A narrowly scoped or phased
replacement could be viable under different constraints, and in that form it
starts to resemble evolution anyway. ZibiWorks is weighing a broad replacement
because its problems span the monolith, and at that scope the coordination and
stabilization risk against this deadline is what makes it hard to justify.

Could ZibiWorks buy more time?

The opposite move is to attempt nothing structural: scale out the existing
monolith, survive one more peak season, and defer modernization. It is a
legitimate option, and it turns on a distinction that is easy to blur, between
capacity and architectural resilience.

Horizontal scaling might handle the extra load, assuming Fulfillment's
bottleneck responds to additional compute. But more instances do not give
Fulfillment independent deployment or failure isolation, and the shared
constraints stay shared: database contention and synchronous dependencies can
remain, or even worsen as more instances press on the same backend. Scaling the
whole monolith to serve one capability raises cost too, though that is
secondary here.

Leadership asked for two things, scalability and resiliency. Additional
capacity may improve availability, but it does not eliminate the shared failure
risks Fulfillment faces within the monolith. Under lighter constraints, buying a
season of runway could be reasonable. For ZibiWorks it defers the problem rather
than reducing the risk it needs to retire before peak season.

Evaluating the options against the business needs

The choice becomes clearer when each approach is measured against what ZibiWorks
actually needs before peak season.

Decision criterion	Full rewrite	Scale existing monolith	Evolve incrementally
Improve Fulfillment before peak season	Depends on full-platform readiness	Can improve capacity quickly	Can prioritize Fulfillment
Scale Fulfillment independently	Yes, after replacement	No	Yes, after extraction
Improve Fulfillment resilience	Can design for resilience, but benefits arrive with replacement	Can add redundancy; shared failure risks remain	Can improve resilience as Fulfillment is extracted
Isolate Fulfillment from unrelated failures	Yes, with appropriate boundaries	Existing application coupling remains	Yes, with appropriate boundaries
Minimize peak-season deployment risk	Coordinated cutover and stabilization	Smaller immediate change, existing coupling remains	Smaller incremental transitions
Continue broader modernization	Complete replacement	Deferred	Progressive modernization

Leadership's requirements are explicit: improve Fulfillment's scalability and
resilience before peak season. Those are what the first rows measure. The rest,
deployment risk and the ability to keep modernizing, are supporting
architectural criteria rather than mandates, but they shape which option meets
the requirements safely. Read that way, no column strictly dominates. A rewrite
reaches the same target capabilities but gates them behind the whole
replacement; scaling adds capacity fastest but leaves the coupling and
resilience gap in place; evolution can act on Fulfillment first, provided the
extraction and its boundaries hold.

The decision

ZibiWorks chooses evolutionary modernization. It is the clearest path to
improving Fulfillment on its own timeline, without gating that improvement
behind a complete replacement. Scaling the monolith could improve capacity and,
through redundancy, availability, but it does not resolve the shared application
failure modes or give Fulfillment the independent failure isolation leadership's
resilience requirement implies. Evolution's gains are not free: they depend on
successfully extracting Fulfillment behind boundaries that hold. On ZibiWorks'
constraints that is the better bet than coupling Fulfillment's deadline to a
platform-wide cutover.

Under different constraints (no deadline, a smaller system, an appetite for one
coordinated cutover) the rewrite could be the better call. Here, the deadline
and the breadth of the system decide it.

What evolution requires

"Evolve the monolith" is a decision, not yet an architecture. Delivering it
means designing two architectures at once and keeping them distinct.

Target architecture

The system ZibiWorks ultimately wants
Domains, ownership, data responsibilities, integration
Permanent

Migration architecture

The temporary mechanisms that get there safely
Adapters, shims, DI seams, sync paths, fallbacks, routing, bridges
Designed to disappear

Keeping these separate is what stops the migration scaffolding from being
mistaken for the target. The migration architecture is real, designed work, even
though most of it is meant to be removed when the migration is done.

Reversibility, and its limit

One benefit of a designed migration architecture is that transitions can be made
reversible. The monolith depends on an interface representing a business
capability. Dependency injection first resolves that interface to the legacy
implementation; during migration it is swapped for an adapter that talks to a
newly extracted domain. From the monolith's point of view the contract is
unchanged even though the implementation boundary has moved, so routing can be
pointed back at the legacy implementation through configuration. A large
architectural change becomes a sequence of smaller, individually reversible
steps.

But routing rollback is not the same as business-state rollback. Flipping the
switch back is easy at the application boundary; whether it is safe depends on
what has happened to the underlying data. If the new domain has become
authoritative, how can the legacy implementation still be a viable fallback?

ℹ️ Data completeness and data authority are not the same thing

Authoritative writes can move to the extracted domain while the monolith keeps a complete enough representation of the data it needs, maintained from the new domain's events. The new domain owns the writes; the monolith's copy stays current enough for legacy workflows to keep running; the old implementation remains a plausible fallback. Call it dual presence, single authority: the data is present in both places, but only one side is the source of truth.

Completeness is not the same as authority, and it is not the same as safe rollback. Once authority has moved, reversing it also depends on state compatibility, business semantics, and the ability to reconcile whatever each side wrote in the meantime. Asynchronous synchronization keeps the fallback viable; it does not, by itself, guarantee a clean reversal.

Strangler Fig

With evolution chosen and the migration architecture understood, the Strangler
Fig pattern is the strategy that organizes the work. It gives the migration a
repeatable sequence: pick a capability, redirect its responsibility to a new
domain behind the existing contract, let old and new run side by side, move data
authority across once confidence builds, then retire the legacy implementation.
The cycle repeats, one capability at a time, until the monolith has been
strangled. Fulfillment is the natural first candidate, since it is the capability
under the most pressure.

The Scaffolding Fallacy

Most of that migration architecture is built to be thrown away, which invites a
tempting but wrong conclusion: that if something is going to be removed later,
the effort spent building it must be waste. Construction scaffolding is temporary
and is no part of the finished building, yet no one calls it wasted. Its value is
letting the building go up safely. Migration architecture is the same. It can
have no place in the target and still be worth a great deal during the
transition.

The guardrail is that "temporary" is not a license for uncontrolled complexity.
Scaffolding that earns its place has a purpose, a transition it enables, an
owner, and a known removal condition.

Temporary by design is very different from accidentally permanent. The problem
is not throwaway code; it is throwaway code that nobody ever throws away.

Consequences

The decision is a trade made with its costs in view.

What ZibiWorks gains

Fulfillment addressed first, ahead of peak season
Business value arriving earlier, not at the end
Smaller, independently validated transitions
A smaller blast radius per change, with more chances to roll back
Data migration spread across the program
No single platform-wide cutover

What ZibiWorks accepts

Temporary architecture and some disposable code
Coexistence between old and new
Eventual-consistency and synchronization concerns
Added operational complexity during migration
The ongoing job of actively retiring scaffolding

The right column is the price of the left one.

ZibiWorks has now decided to modernize, chosen evolution, and settled on
Strangler Fig as the approach. But a strategy is not a cut line. Before the
system can come apart safely, ZibiWorks has to understand where its real
boundaries are, and that starts with the language the business uses to describe
them.

ZibiWorks is fictional. The ideas and opinions expressed throughout the series are my own and do not represent the views, positions, or practices of my employer.

Move It or Fix It First?

Bob Palermo — Wed, 07 Oct 2026 14:14:56 +0000

Leadership wants to move to the cloud. Before evaluating that answer, separate what migration solves from what modernization solves.

"Move to the cloud" is a reasonable instinct, and it comes from real pressure.
But it is a solution, not a problem. Before evaluating it, the job is to work
out what moving would actually solve, what it would leave untouched, and whether
the timing even makes sense.

What leadership is actually reacting to

Behind "move to the cloud" is a stack of legitimate pressures: hardware
approaching its refresh cycle, a rising operational burden in the data center,
disaster-recovery expectations that are getting harder to meet, seasonal demand
that forces sizing for peaks, environment provisioning that takes too long, and
a reluctance to sign off on another large capital investment just as the company
expects to grow.

ZibiWorks also has a separate, well-known set of problems in the application
itself, established back in The Starting
Point: risky monolithic releases,
teams colliding in one codebase, a shared database, tightly coupled business
domains, brittle partner integrations, and no way to scale business capabilities
independently.

Both lists are real. The trap is treating them as one problem with one answer.
Sort the pressures by what kind of problem they are, and a pattern shows up:
some are about where the application runs, and some are about how it is
built. A third set is not a problem class at all. These are the constraints and
timing that shape when and how either kind of change can happen.

Where it runs (infrastructure)

Hardware refresh and OS lifecycle
Disaster recovery
Capacity planning and seasonal peaks
Slow environment provisioning
Data-center burden and capital expenditure

How it is built (application)

Tightly coupled business capabilities
Shared database
Monolithic, risky deployment
Brittle partner integrations
No independent scaling of capabilities

Constraints and timing

Systems that must stay on premises
Unsupported runtimes or licensing limits
Prepaid or committed licenses
Upcoming renewals, refreshes, or growth events

Migration and modernization solve different problems

Migration changes where the application runs. Modernization changes how it is
built. They are not rival strategies so much as answers to different questions,
and the split in the pressures above maps almost cleanly onto them.

Pressure	Migration helps?	Modernization helps?
Hardware refresh, DR, seasonal peaks	High	Low
Slow environment provisioning	High	Low
Monolithic, risky releases	Low	High
Shared database, domain coupling	Low	High
Brittle partner integrations	Low	High
Systems that must stay on premises	Negative / adds complexity	Neutral

The one line to carry out of this installment:

Moving the monolith to the cloud does not un-share the database or untangle the domains. Modernizing in place does not replace aging hardware or fix DR.

That is why "migrate or modernize" is a false binary. The real options sit on a
spectrum: modernize in place, migrate largely as-is, migrate with
selective remediation, or migrate and modernize together. Doing both at
once addresses the most problems, which is exactly why it is tempting, but it
also carries the most cost, the longest duration, the heaviest coordination, and
the greatest execution risk. The question is not which option is best in the
abstract. It is which sequence fits ZibiWorks right now.

What narrows the decision

Sequencing is decided less by architecture than by lifecycle, money, and
dependencies. Three facts do most of the work.

Timing and economics. Much of what makes a move cheap or expensive is not
technical at all. The cost of leaving and the cost of staying both turn on where
ZibiWorks sits in the hardware, license, and contract lifecycle, and that
position changes constantly.

ℹ️ Timing is part of the architecture

The same decision flips with the calendar. A migration that looks unattractive the month after a hardware purchase can look obvious when that hardware is a year from replacement. Note when things expire, not just what they are.

Dependencies. A workload's readiness to move is partly set by the systems
around it, and ZibiWorks does not run in isolation.

Legacy dependencies do not automatically block a move; they change its cost and
shape. Some can move, some cannot move yet, and anything that must stay on
premises turns a clean migration into a hybrid one, with private connectivity
and latency to manage.

Whether the move is even necessary. It is worth saying plainly that if the
current infrastructure had years of life left, met capacity and recovery needs,
and was cheap to run, delaying the move could be the right call. Migration has
to earn its place against simply modernizing where the system already runs.

How ZibiWorks lands, and why

For ZibiWorks, those facts line up in one direction. The hardware refresh is
approaching and major licenses are nearing renewal at roughly the same time.
Recovery expectations are rising faster than the data center can meet them,
seasonal peaks force expensive over-provisioning, and expected growth would
otherwise trigger a fresh round of infrastructure investment. Environment
provisioning is already too slow for the delivery pace. On the application side,
the monolith can run in the target cloud with manageable remediation, and the
few legacy systems that must stay on premises can be reached over private
connectivity. Crucially, full modernization would take far longer than the
infrastructure lifecycle allows.

Put together, the infrastructure clock is forcing a decision now, and the
application work cannot be finished on that timeline. So:

Move now. Modernize next. Change only what is required to make the move safe and useful.

That is migration with selective remediation: not a blind lift-and-shift,
and not a big-bang modernize-while-moving. Under different facts (new hardware,
prepaid licenses with years left, no growth event, healthy DR), the same
reasoning could land on "stay and modernize." The decision follows the
constraints, not a preference for one strategy.

What gets fixed now, and what waits

Selective remediation only works if the line between the two is explicit. The
deferred items are real and important; they simply do not need to be solved to
move the application safely. Keeping that line clear is what stops the move from
sliding into a rewrite.

Fix now: migration blockers

Repeatable, automated deployment
Externalized environment configuration
Remove hard dependencies on server identity
Health checks
Baseline observability
Reliable backup and recovery
Infrastructure automation
Connectivity to systems staying on premises
Anything unsupported in the target environment

Defer: non-blocking modernization concerns

The shared database
Business-domain coupling
Monolithic deployment
Brittle integration boundaries
Most code-level modernization work

A known problem can be deliberately deferred when solving it is not required to
reach the current objective. That is a discipline, not an oversight.

⚠️ When "later" becomes "never"

Deferring modernization is a deliberate decision, but it carries a risk. Once the migration is complete and the immediate infrastructure pressures are gone, the urgency to address those architectural problems may fade. "Migrate now, modernize later" can quietly become "migrate now, modernize never."

That does not make migration-first the wrong choice. It means the deferred work has to stay visible as part of the broader modernization effort.

What the move leaves behind

After the move, ZibiWorks has better infrastructure automation, better recovery,
faster provisioning, a more flexible capacity model, and less dependence on
physical hardware. The platform is in a better position to evolve. But when the
teams open the codebase again, the same problems are waiting: the monolith is
still a monolith, the database is still shared, the business capabilities are
still tightly coupled. ZibiWorks chose not to solve those during the move. Now
it is time to.

The next question is whether to replace the application or evolve it.

ZibiWorks is fictional. The ideas and opinions expressed throughout the series are my own and do not represent the views, positions, or practices of my employer.

What's Driving Change?

Bob Palermo — Mon, 05 Oct 2026 12:33:27 +0000

Before designing anything, find where the current platform is starting to limit the business, and which touch points deserve a closer look.

ZibiWorks believes they need to modernize, but that conclusion did not come from an architecture diagram. It came from mounting pressure on the business and the teams supporting it. Changes take longer than they should. Deployments carry more risk. Partner integrations are getting harder to manage. New customer experiences and connected-product capabilities are placing demands on a platform that was built for a simpler business.

Those pressures are real, but they do not yet tell us what architecture to build. The instinct is often to jump directly to services, a message bus, the cloud, or a cleaner data model. That is premature. Before choosing an architecture, we need to understand where the current one is actually getting in the way, what business outcomes are being affected, and which problems are significant enough to justify change.

So this installment is about where modernization should start, not what to build. We will identify the business and technical pressures worth addressing, turn them into an initial set of success criteria, and establish the guiding principles that later architecture choices can be weighed against. Those criteria and principles become the decision lens for everything that follows.

What should guide the decision?

Before choosing an architecture, we need to know what should guide the choice.
That comes from combining two things: the business context, which tells us what
matters, and the technical context, which tells us what is feasible,
sustainable, and responsible to build and operate. The business rarely asks for
"changeability" or "resilience" by name; those are architectural
interpretations. Neither side provides the answer alone.

In brownfield work that business context often shows up as existing pain; in greenfield
work it more often arrives as goals, constraints, and assumptions. Either way,
the two inputs are:

Business context

Desired outcomes and business capabilities
Where the pressure is (for ZibiWorks, existing pain)
Cost, delivery, and timing
Customer expectations and growth assumptions
Risk tolerance and regulatory constraints

Technical context

Current platform capabilities, where one exists
Available technology choices and constraints
Team skills and operational maturity
Resilience, security, data integrity, observability
Technical debt (where applicable) and cost to operate

Combining the two produces the first useful output, and it is not a target
architecture. It gives us two things we can use to evaluate architecture
choices: success criteria, which describe what needs to improve and how we
will know, and guiding principles, which describe how we make decisions
while pursuing those improvements.

Those criteria and principles become the lens for the decisions that follow.

These are working criteria and principles, not commandments. As the business and
technical context change, the decision lens changes with them.

For ZibiWorks, then, the first step is not to redesign the platform because the
architecture looks old. It is to find where the current architecture is actually
creating meaningful friction, trace those pressures into the platform, and mark
where architectural change might create leverage, stopping short of choosing a
solution. Each pressure below follows the same path:

Business pressure → Business constraint → Architectural touch point → Options examined later

The platform still works

The platform is doing its job. Orders are placed, Zibis are shipped, customers and partners are served. The business is operating.

The original architecture was a good fit for an earlier ZibiWorks. What changed is the business around it. Growth has changed the consequences of the original tradeoffs.

The result is not a broken platform. It is a working platform beginning to show wear in a few important places. Those pressures are where the rest of this installment focuses.

Pressure 01 · Brittleness: The platform is getting harder to change safely

Over time, ZibiWorks' concerns have grown into one another. Orders reach into
Pricing, Inventory, Payments, Fulfillment, Shipping, Customer, and Zibi
Lifecycle, with product and catalog logic close behind. Shared models span
several business areas. Entity Framework entities flow upward through the stack.
Common models are reused broadly, and shared tables carry ambiguous ownership.

No single one of these dependencies is wrong. An Order genuinely needs pricing
and inventory. The trouble comes from how many of them accumulate and cross
through the same shared models, so a change in one area rarely stays in one
area.

A local change around Orders rarely stays local, because Orders is entangled with several surrounding concerns.

Interwoven concerns → Larger blast radius → Broader testing → More coordination → Slower delivery

A local change can have non-local effects. Making a change safely takes broader
knowledge of the system, regression testing expands, releases need more
coordination, and one change is harder to isolate from everything else.

Pressure 02 · Partner Coupling: External change has become an internal delivery problem

ZibiWorks depends on PayPaw, Handle With Care, Paw & Circuit, RoboMotion
Systems, and HomeSphere. As covered in The Starting
Point, partner-specific fields,
statuses, identifiers, workflows, payload shapes, and batch formats have worked
their way into internal logic and shared models.

Partner change now reaches beyond the partner boundary.

The business impact is specific: a partner change can require changes in parts
of ZibiWorks that look unrelated to that partner. A new API version, changed
payload, revised status model, new capability, deprecated interface, or new
compliance requirement can all ripple inward.

There is a second cost that is easy to miss. Because the integrations are woven
so deeply into the platform, ZibiWorks may not be able to adopt a better
partner API or a new partner feature quickly. That quietly limits its options.

Pressure 03 · Growth: Each new capability increases the cost of the next one

ZibiWorks wants to expand: more connected Zibis, more partners, more
customer and internal capabilities, new products and services, more reporting,
and eventually new platform opportunities. The current platform can support all
of it. The problem is that each new capability tends to make the next one
harder. That points at a kind of scalability people often skip past.

Runtime scalability

More requests
More transactions
More connected devices
Can the infrastructure handle growth?

Change scalability

More capabilities
More teams changing the system
More dependencies and coordination
Can the organization keep changing safely?

Scalability is not only about runtime capacity. Runtime scaling and change
scaling are different problems. Right now, change scalability is the bigger
problem.

Pressure 04 · Capacity: Normal demand or peak demand?

ZibiWorks runs on traditional infrastructure, so it has to size capacity
ahead of demand. Demand is not steady. Holidays, promotions, product launches,
partner campaigns, and seasonal buying all push it around.

Size for normal demand: lower steady-state cost, greater peak risk.
Size for peak demand: more headroom, more idle capacity.

The architecture makes this sharper. Much of the platform scales as a
coordinated unit, so a spike in one area can force ZibiWorks to add capacity
broadly rather than where the load actually is. The conclusion is not that cloud
is the answer. ZibiWorks needs a better answer to variable demand, and cloud
elasticity may eventually be one option worth weighing.

Pressure 05 · Customer Experience: Reliability is becoming part of the product

ZibiWorks is increasingly customer-facing. When the platform mostly supported
internal operations, downtime was an internal disruption. As more of it faces
customers, downtime becomes something customers see: a slow storefront, a failed
checkout, account functions that will not load, delayed order information,
Zibi management that is unavailable, connected features that degrade.

This connects directly to the capacity pressure. The periods of highest customer
demand are often the periods of highest infrastructure strain, so a capacity
shortfall tends to show up as a customer-facing outage at the worst possible
time.

Customer demand ↑ → Infrastructure pressure ↑ → Performance / availability risk → Customer experience

Reliability and scalability are becoming part of the customer experience, which
raises later questions about resilience, observability, failure isolation,
graceful degradation, and recovery.

None of these pressures selects an architecture. They mark where the current
platform constrains the business. Patterns and technologies come later.

From business pressure to architectural touch point

Each pressure points at an area of the architecture worth examining later. These
touch points show where the series will look next without assuming the eventual
solution.

Business pressure	Architectural touch point
Changes ripple	Boundaries, dependency structure, modularity
Partner blast radius	Integration boundaries, anti-corruption layers (ACLs), contract isolation
Growth cost rises	Extensibility, deployment boundaries, incremental evolution
Variable demand	Scaling model, workload isolation, elasticity
Visible downtime	Resilience, failure isolation, observability, recovery
Ambiguous ownership	Domain modeling, data ownership, contextual models
Diverging experiences	API boundaries, consumer-specific contracts
Reporting pressure	Analytical separation, read models, data movement

Sorting what is fine from what is not

Not everything imperfect in the platform is worth changing. Some of what looks
dated is still doing its job perfectly well, and some of what works today is
already starting to strain. The point of sorting is to separate the parts that
are fine from the parts that are actually costing the business something.

Still serving the business

.NET
SQL Server
Entity Framework
Responsive web application
Relational transactions
Shared deployment where it still simplifies operations

Creating measurable friction

Cross-domain business coupling
Ambiguous data ownership
Partner logic inside core services
Coordinated deployment
Broad regression impact

The business is beginning to require

Stable API contracts
Additional user experiences
More independent scaling
Clear telemetry and state ownership
Separation of operational and analytical workloads
Higher customer-facing availability

If this does not materially affect delivery speed, risk, scalability, availability, security, cost, or a business capability, why are we changing it?

We carry forward only the areas where a technical constraint can be tied to
meaningful business impact.

The initial decision lens

The pressures point to five areas worth deeper investigation. Together they
become the first working success criteria for ZibiWorks: for each, the
current strain and what improvement would look like.

Area & current strain	What success looks like
Changeability. Cross-domain coupling, shared ownership, and broad regression impact are raising the cost of change.	A smaller blast radius, less regression and coordination effort, and more changes that stay local.
Extensibility. Partner coupling and the rising cost of adding capabilities make external change expensive.	Less effort to absorb partner and capability changes, with fewer unrelated areas affected.
Scalability. Variable demand and increasingly different workload profiles expose both runtime and change-scaling constraints.	Handling variable demand without scaling the platform as one unit, while improving the system's ability to absorb ongoing change.
Reliability. Performance and availability problems are becoming visible to customers.	Fewer customer-visible failures, with better failure isolation and recovery where the business impact justifies it.
Data. Ambiguous ownership and competing operational and analytical needs are creating friction.	Clearer ownership and meaning, with less interference between operational and analytical workloads.

These are directions, not numeric targets. The evidence tells us what needs to
improve; the levels worth committing to come as specific decisions get made.

These criteria describe what needs to improve. The guiding principles describe how ZibiWorks should make decisions while pursuing those improvements. They are not intended to map one-to-one to the criteria; most apply across several of them.

Favor change isolation where coupling is materially slowing delivery.
Improve resilience where failures are becoming customer-visible.
Prefer reversible changes while the cost of being wrong is high.
Add complexity only when it buys a capability the business actually needs.
Preserve simplicity where the current design is still serving the business.
Design for foreseeable growth, not every theoretical future.
Treat security, data integrity, and operability as baseline constraints.

These are ZibiWorks' first working criteria and principles, not permanent rules.
They give the next decisions a consistent starting point and will be revisited
as the context changes.

With the pressures identified, the criteria named, and the principles in hand,
ZibiWorks can take on its first real choice: do we address these constraints
before moving the platform, or move first and modernize afterward?

ZibiWorks is fictional. The ideas and opinions expressed throughout the series are my own and do not represent the views, positions, or practices of my employer.