Chapter 3 · Bounded Concerns Architecture

Chapters 1 and 2 established the frontier and described the destination. The Nadella Line separates two futures of software, and the Agentive World is the side organizations will cross to over the coming decade. But before describing the architecture of the destination — the task of Chapter 4 — we must look carefully at the place from which one departs. The vast majority of organizations that will cross the line will not do so by building from scratch: they will do so by transforming a patrimony of enterprise systems that have operated for decades, sustain the heart of the business, and cannot be switched off during the crossing.

This chapter describes that point of departure with the same rigor with which the rest of the book describes the destination. The instrument we will use is called Bounded Concerns Architecture — BCA for short. It is not an architecture of the Agentive World: it is the formal cartography of the state prior to the crossing, designed so that an architect can look at an existing enterprise system, identify where each responsibility lives, and reason in a disciplined way about which components will migrate to the Agentive World, which components will disappear, and which components will remain as invisible backend infrastructure that agents consume without the human ever seeing it.

The choice of name is not ornamental. Bounded captures the operational principle that sustains the entire architecture: each responsibility occupies its place and does not overflow into the territory of the neighboring responsibility. That discipline, which in the pre-agentive era was a recommended best practice, becomes a condition of viability the moment the system begins to incorporate agentic components. Without that discipline, the statistical volatility that agents bring with them contaminates the stable core of the business, and what had worked for twenty years ceases to be reliable. With that discipline, the agentic incursion stays confined to the layer that is designed to tolerate volatility, and the business core stays protected throughout the crossing.

BCA is the architecture of the transition, not the architecture of the destination. It describes the state from which one crosses the Nadella Line, not the state into which one crosses.

The Agentic era demands explicit architectural treatment

The incorporation of agents into enterprise systems is not the addition of yet another new technology. It is the introduction of a class of behavior whose nature is structurally distinct from traditional code, and which therefore demands distinct architectural treatment.

Traditional code — workflows, rule engines, service classes, orchestration scripts — has a common property: its behavior is explicitly specified by humans. Someone wrote, step by step, what happens when, in what order, under what conditions. To understand what it does, it is enough to read the code. Its evolution is deliberate: when it changes, someone decided to change it and modified the corresponding code.

Agentic code — agents based on language models, recommendation systems, machine-learning optimizers, expert systems — has the opposite property: its behavior is contextually derived from a model. No one programmed step by step what it does; someone described an objective or a pattern, and the entity derives the behavior from its weights, training data, prompts, or heuristic rules. To understand what it does, it is not enough to read the code — one must understand the data or the model from which the behavior emerges. Its evolution is statistical: when it changes, it is not because someone modified a line but because the data, the weights, or the prompts that synthesize the reasoning changed.

This difference has four concrete architectural consequences that separate agentic components from traditional ones. Procedural components are tested with deterministic unit tests; agentic ones are tested with evaluation datasets and aggregate metrics. Procedural ones produce predictable logs that reflect code execution; agentic ones produce logs that require interpretation because the behavior varies with context. Procedural ones are auditable line by line; agentic ones are auditable by their inputs, outputs, and metrics but not by their internal logic. Procedural ones evolve through code refactoring; agentic ones evolve through retraining, prompt tuning, or model swaps. These four properties are distinct enough to justify the architecture treating them as separate citizens.

The structural threat this difference introduces into the enterprise system is the following: agents are volatile, but the invariants of the business cannot be.

An agent evolves rapidly. It changes with every update to the underlying model, with every prompt adjustment, with every incorporation of new tools or new data. Its behavior can vary between two identical invocations. Its correctness is not binary but statistical: it operates correctly most of the time, with a tolerable error threshold that depends on the use case.

The invariants of the business are the opposite. A customer has a unique identifier. An invoice has a total that equals the sum of its lines. An activated service has an activation date. These rules admit no statistical errors: either they hold always or the system ceases to be reliable. Their correctness is binary, their rate of change is structural, and their violation has serious regulatory, financial, or operational consequences.

When an agent and an invariant coexist in the same architectural layer with no explicit frontier between them, the volatility of the first contaminates the reliability of the second. Every update to the agent risks breaking invariants that had worked correctly for years. Every change of prompt may inadvertently alter compliance with a regulatory rule. Auditing becomes impossible because there is no longer any separation between what was deliberately programmed and what the agent decided contextually.

The thinness of the domain as the answer

The operational answer to this threat is what we will call the thinness of the domain. If the authoritative core of the system — where the invariants and the persistence of the business truth live — is kept strictly thin, admitting only what is structural to the domain and expelling all volatile logic outward, then the agentic incursion stays confined to the layer that is designed to tolerate volatility. Agents operate in the orchestration logic, alongside the traditional procedural workflows, and both invoke the core as a service with a stable contract. The heart of the business stays protected.

This is the operational position that sustains the entire architecture. Keeping the domain thin is not an aesthetic preference but a necessary condition for procedural and agentic capabilities to coexist in a single system without the latter corroding the reliability of the former.

The distinction between Systems of Record and Systems of Engagement, articulated by Geoffrey Moore¹, operates convergently with this thesis but at a different level. Moore distinguishes between two categories of systems according to their purpose and their rate of change: Systems of Record store the authoritative state of the business and derive their value from their reliability, which demands stability; Systems of Engagement mediate interaction and derive their value from their capacity for adaptation, which demands speed. Forrester² would later extend the taxonomy by adding Systems of Insight, oriented toward knowledge generation. Moore’s dichotomy operates at the level of a systems inventory — which systems an organization has; the thinness of the domain operates at the level of code organization within a component. Both converge on the same fundamental intuition, which Buschmann and colleagues³ articulate in terms of the Layers pattern as a decomposition criterion: each layer should have a distinct and specific responsibility with respect to abstraction, granularity, or rate of change. The Agentic era intensifies this logic: agentic components change at an even faster rate than traditional commercial policies — model rate, not business rate — and must therefore be kept architecturally even further from the stable core.

The thesis holds a specific position on the hierarchy of architectural decisions. Other frequently debated decisions — the choice between a monolithic or microservices architecture, the direction of dependencies, the degree of event-sourcing adoption, the command/query separation, the deployment modality of agents — are important but subordinate. They operate within a space whose shape is determined beforehand by the decision about where the domain ends. A microservices architecture with obese domains where agents are introduced reproduces the problems of a poorly structured monolith, now distributed and with additional agentic volatility. A hexagonal architecture with a core that mixes invariants and workflows uses the correct direction of dependencies to protect a poorly designed core, but the incorporation of agents into that core invalidates the protection. A thin domain, by contrast, produces a component whose core is stable, whose rules are auditable, and whose integrations — procedural or agentic — are interchangeable.

Keeping the domain thin requires a concrete architectural operation: drawing an explicit frontier between the domain and the orchestration logic, and defending that frontier against the incremental drift that tends to fatten the core over time. The Bounded in the model’s name takes up the principle of Separation of Concerns articulated by Dijkstra⁴: the discipline of studying one aspect of a problem in depth, for its own consistency, knowing all the while that it is only one among several. Dijkstra’s separation is originally cognitive. Its transformation into an architectural principle over the following decades — visible in patterns such as Layers⁵, Hexagonal⁶, Clean Architecture⁷, and DDD⁸ — produces the theoretical lineage to which BCA belongs. The difference between BCA and its predecessors lies in which specific frontier is chosen as the most consequential: BCA chooses the frontier of the domain, and upholds it as a condition of viability for the Agentic era.

The three layers

BCA decomposes an enterprise component into three layers. Layer 1, Presentation, contains the component’s two external frontiers: UI toward humans and API toward systems. Layer 2, Business Logic, contains the orchestration logic, organized in two parallel boxes: Procedural for explicitly programmed behavior, Agentic for contextually derived behavior. Layer 3, Domain, contains the stable core of the component, organized along two orthogonal dimensions: own domain versus foreign domain on the vertical axis, logic versus persistence on the horizontal axis.

Layer 1 treats UI and API as parallel citizens, not as variants of the same concern. UI is the controllers, views, and handlers that mediate interaction with humans; it evolves at the rate of UX needs. API is the endpoints, contracts, routing mechanisms, and versioning policies that mediate interaction with other systems; it evolves at the rate of the component’s public contracts, under specific constraints of backward compatibility and precise semantics⁹. In the pre-agentive era this separation was a microservices best practice; in the Agentic era it takes on additional relevance, because agents can operate both on the UI (assisting the human user) and on the API (consuming and producing machine-to-machine contracts), and recognizing the distinction makes it possible to manage their respective modes of invocation appropriately.

Layer 2 contains the orchestration logic: the logic that knows which steps make up a use case, in what order they occur, what happens if one fails. Here lives the seventh canonical separation of the model, which we will return to in detail further on. Procedural comprises all logic whose behavior is explicitly programmed by humans: process engines, rule engines, sagas, choreography frameworks, workflow orchestrators, service classes, coordination scripts. The operative distinction is not one of technology but of nature: the behavior is coded step by step by a human and can be understood by reading the code line by line. Agentic comprises the components whose behavior is contextually derived from a model, not from a coded sequence. The two boxes share a layer because both are orchestration logic — both operate on the domain without forming part of it — but their distinct operational nature justifies treating them as parallel citizens.

The frontier between Layer 2 and Layer 3 — between orchestration and domain — is the operational frontier of the thesis. Layer 3 contains exclusively logic that the business considers structural; everything else lives in Layer 2, whether Procedural or Agentic. The operative criterion is temporal in nature: if a rule can change as a consequence of a commercial decision without altering the fundamental model of the business — or if the rule is statistically derived rather than explicitly coded — it belongs in Layer 2; if the rule is structural to the domain and changing it would imply a change in the very nature of the business, it belongs in Layer 3.

Layer 3 is organized along two orthogonal dimensions that produce four cells. The vertical dimension separates the own domain from the foreign one: the SOR (System of Record) column contains the components that model data whose authority belongs to the system — the authoritative core, what is validated, what is persisted as truth, what emits events when it changes; the External column contains the components that know, translate, and locally represent data whose authority lives outside, in systems with which the component collaborates — CRMs, external billing, provisioning OSS, B2B partners, third-party APIs. The horizontal dimension separates logic from persistence: the Logic band contains the invariants in SOR and the translations from the foreign model in External; the Persistence band contains the physical storage mechanisms.

Each of the four resulting boxes is internally subdivided into a synchronous path and an asynchronous path. The lexical asymmetry between Streams (SOR side) and Hooks (External side) is deliberate. On the SOR side the system emits its own facts and persists them as an appendable log; authorship is its own and the direction is outgoing. On the External side, events arrive because external systems push them via webhooks or equivalents; authorship is foreign and the direction is incoming. Calling both Streams would lose that important directional information.

The seven structural separations

Taken together, the decisions of the three layers produce seven explicit structural separations. Each one responds to the classic observation that differentiated concerns have distinct rates of change, distinct audiences, and distinct semantics, and therefore deserve distinct architectural treatment.

Separation 2 is the operational frontier of the thesis. Separations 3 through 6 structure the internal content of Layer 3. Separation 1 structures the internal content of Layer 1. And separation 7 — the seventh canonical separation — structures the internal content of Layer 2 by explicitly reflecting the dual nature of orchestration logic in the Agentic era.

Each cell of the architecture has its own rate of change. SOR · Logic and SOR · Persistence change at the rate of the evolution of the fundamental business model — years or decades. External · Logic and External · Persistence change at the rate of the external systems they serve. Business Logic Procedural changes at the rate of commercial policies — months. Business Logic Agentic changes at the rate of the underlying models — weeks or days. API changes at the rate of public contracts. UI changes at the rate of UX needs. This differentiation justifies distinct versioning, deployment, and testing policies for each cell, and it is the structural reason why the seventh separation is necessary: the Agentic rate is fast enough to require its own regime.

Intellectual genealogy

BCA does not invent primitives. It synthesizes patterns published, debated, and refined by the software architecture community over the past two decades, reorganizes them around an explicit operational principle — the thinness of the domain — and repositions them in relation to an emerging phenomenon: the incorporation of agentic capabilities into enterprise systems. Every decision of the model is anchored in prior literature.

The frontier between Layers 2 and 3 — between orchestration and domain — comes directly from Fowler¹⁰. In Patterns of Enterprise Application Architecture, Stafford — author of the Service Layer pattern in that work — articulates the distinction between domain logic, which has purely to do with the problem domain, and application logic, which has to do with application responsibilities such as notifications, integrations, and workflows. Fowler reinforces the distinction in Domain Logic and SQL¹¹ and acknowledges its practical limits in Organizing Presentation Logic¹². The separation between logic and persistence within Layer 3 follows from the Data Mapper and Repository¹³ patterns, whose explicit purpose is to keep the domain model clean of storage details.

The Domain Layer as a container of invariants comes from Evans¹⁴. In Domain-Driven Design he proposes a four-layer architecture (UI / Application / Domain / Infrastructure) that coincides structurally with BCA, with two deliberate differences: BCA bifurcates the domain into SOR and External, explicitly incorporating integration with foreign systems as a full citizen of the domain; and BCA separates persistence from the domain within the same layer, whereas in Evans persistence lives in Infrastructure.

BCA deliberately departs from canonical DDD on one specific point: the placement of Domain Services. Under canonical DDD, Domain Services — the logic that coordinates multiple aggregates — belong to the Domain Layer. BCA places them in Business Logic. The reason is the temporal asymmetry articulated earlier: Domain Services frequently contain commercial policies that change with the business (eligibility policies, discount rules, approval procedures), whereas the structural invariants of the domain change at a fundamentally slower rate. In the Agentic era this asymmetry intensifies: part of the coordination becomes the responsibility of agents, which adds statistical volatility to the temporal volatility already present. Vernon¹⁵ discusses the tension between Domain Services and Application Services without resolving it in a single direction, recognizing that the choice depends on context. BCA takes a position.

The philosophy of the asynchronous leg is anchored in Helland¹⁶. Data on the Outside vs. Data on the Inside articulates that authoritative data lives inside a service in a transactional world with serializable changes, while data that circulates between services is immutable. A decade later, in Immutability Changes Everything¹⁷, Helland goes deeper: domain facts are intrinsically immutable — events that occur cannot be erased; corrections are new events. Kleppmann¹⁸ synthesizes this tradition by articulating that mutable state and event log can coexist as complementary representations of the same domain, a position that is the conceptual basis for the coexistence of Repository and Streams in BCA’s SOR column.

Young¹⁹ articulates CQRS by arguing that the command side should be thin and focused on protecting invariants; process logic lives in sagas and process managers that coordinate the SoRs, not within them. BCA adopts the spirit of CQRS without going all the way to strict CQRS: the synchronous cells of Layer 3 are thin, the asynchronous cells exist as complementary citizens, but mutable state and event log coexist rather than one deriving from the other. Fowler²⁰ synthesizes Young’s position in his bliki entry on CQRS.

The External column of Layer 3 generalizes the Anti-Corruption Layer pattern originally proposed by Evans²¹ and refined by Vernon²² with specific focus on how bounded contexts integrate with one another. Vernon explicitly articulates that integration with legacy systems is one of the paradigmatic cases where the pattern applies.

The separation of the API as a distinct architectural concern does not appear in the classic texts of Fowler²³, Evans²⁴, or Moore²⁵, but it is established practice in modern microservices architecture. Newman²⁶ devotes entire chapters to API design decisions, explicitly separating them from presentation to the user. The asynchronous leg rests on the formal catalog of messaging patterns by Hohpe and Woolf²⁷ — their 65 patterns constitute the vocabulary of the Events, Streams, and Hooks cells. In the telco context specifically, the TM Forum²⁸ classifies the functional blocks of the Open Digital Architecture according to Moore’s dichotomy: Party Management, Core Commerce Management, and Production as SoR; Engagement Management as SoE; Intelligence Management as SoI. The adoption of the SOR column in BCA is consistent with this classification: if TMF already defines certain functional blocks as SoR, it makes sense for the logic that resides within them to be consistent with the purpose of a SoR according to Moore.

The seventh canonical separation — Procedural / Agentic — and the repositioning of the model as the architecture of the pre-agentive state are anchored in The Agentive Future²⁹ and in this book. There, the Nadella Line is articulated as the conceptual frontier between two possible worlds for enterprise software. BCA takes a specific position: it is the architecture of the Agentic transition, and it yields the floor to the Agentive Architecture framework of the Agentive World (Chapter 4) when the organization crosses the line.

Comparative map of proposals

The proposals mentioned in the genealogy coexist in the architectural conversation as an archipelago where each author draws lines in different places. The figure that follows situates them on a two-dimensional map that makes it possible to visualize how they relate to one another and why BCA’s position is a choice, not the only reasonable option.

The map is built on two dimensions whose methodological nature is deliberately distinct. The X axis is measurable along a discrete scale of five levels. The Y axis is qualitative and is built through an interpretive inference that the following section formalizes.

The X axis — Domain thickness measures how much logic the component that handles authoritative data accumulates. The levels are cumulative: each level includes what is in the lower levels. Level 0 — Pure DAO: only CRUD over storage, with no invariants or auditing; it does not qualify as a domain in the strict sense. Level 1 — Strict domain: adds the aggregate’s intrinsic invariants, stable identity, and change auditing. It is the thickness the thesis defends as optimal for the Agentic era. Level 2 — Multi-entity: adds operations that coordinate several aggregates of the same domain (Domain Services). Level 3 — +policies: adds changeable commercial rules (campaigns, discounts, eligibility restrictions). Level 4 — +workflows: adds orchestration of complete processes with multiple steps and external integrations.

The Y axis — Theoretical rigor vs real-world flexibility measures how dogmatic the proposal is about requiring its separation. At the purist pole are the proposals that hold “if you don’t separate strictly, you’re not really doing X”. At the pragmatic pole are the proposals that explicitly acknowledge that the conceptual line gets messy in practice. The pragmatic pole reflects exactly the caveat that Fowler³⁰ acknowledges about layered architectures.

The positions reflect the stance of the original author of each proposal, not the interpretations that the various communities have made of them. In the upper-left quadrant — purists with a minimal core — live strict CQRS³¹ and Data on the Inside³². Both proposals demand a thin domain and are dogmatic about it. In the upper-middle quadrant — purists with architectural frameworks — live Clean Architecture³³ and Hexagonal³⁴. Both define strict rules about the direction of dependencies and the separation between domain and infrastructure, but allow a certain multi-entity richness within the core. In the upper-right quadrant — purist with a thick core — lives canonical DDD³⁵, refined by Vernon³⁶. It accumulates more logic within the Domain Layer through Domain Services but with strict discipline over Bounded Contexts, Anti-Corruption Layers, and well-delimited aggregates.

In the intermediate zone sits Bounded Concerns Architecture. On the X axis it coincides with CQRS and Helland (level 1, strict domain). On the Y axis it lands in the intermediate zone: it adopts the formality of Fowler and Moore at the frontier of the domain (what enters and what does not), but is pragmatic about the internal implementation of the component, recognizing that in enterprise systems with COTS products one does not have control over the internal organization of purchased software, and that in the Agentic era the Agentic components introduce an additional layer of variability that requires operational flexibility.

In the lower-middle quadrant — declared pragmatic — lives Service Layer³⁷. It is the most explicitly pragmatic of the mature proposals: Fowler³⁸ himself writes that the distinction between application logic and domain logic gets messy in practice. In the lower-right quadrant — pragmatics with a thick core — live Active Record³⁹ and the classic 3-layer⁴⁰. Active Record was designed for productivity — Rails’s motto “convention over configuration” is its ethos. The classic 3-layer, without additional architectural discipline, tends to accumulate entire workflows within the Business Logic layer mixed with persistence.

The map is an orientation tool, not an official classification. Three reading precautions. First, the positions reflect the stance of the original author; different communities have interpreted the same proposals with greater or lesser rigor (there is DDD-lite and there is orthodox DDD). Second, the Y axis is qualitative and depends on an interpretive inference that the following section formalizes. Third, this map covers proposals for organizing the interior of a component; it does not speak to integration patterns between components, which are orthogonal and are cataloged in other works⁴¹⁴².

Scoring model for the qualitative axis

The Y axis of the map situates the proposals along a qualitative dimension of “theoretical rigor vs real-world flexibility”. This position does not come from the sources — Fowler never wrote that CQRS is more purist than Service Layer in formal terms — it is an interpretive inference constructed from reading the sources.

For that inference to be verifiable and debatable, “pragmatism” is decomposed into five observable dimensions, each scorable from 0 to 3 according to explicit textual criteria. The resulting sum (0 to 15) situates each proposal on the Y axis, where 0 represents maximum purist rigor and 15 represents maximum pragmatic flexibility. This model does not pretend to produce a definitive score. It aims to make visible and disputable the reasoning that led to each placement. Any reader with access to the primary sources can recalibrate the cells and obtain a different position — that is desirable, not a defect.

D1 — Normative language. Does the proposal use phrases of the type “you must / never / always / strict / must” about the separation, or does it use “consider / often / it depends / frequently”? D2 — Acknowledgment of the practical gray. Does the proposal explicitly admit cases where applying the rule causes harm, or does it defend purity in every scenario? D3 — Permissiveness toward lite variants. Are there flexible variants tolerated or promoted by the original author? D4 — Focus. Does the proposal aim to reorganize the entire system, or is it offered as one pattern among many in a toolbox? D5 — Compatibility with legacy systems. Does the proposal offer paths to integrate with existing systems that do not follow it, or does it demand greenfield?

Applying this to the evaluated proposals produces the scores in the table that follows.

The scores produce a correlation that supports the chapter’s thesis. The proposals with the lowest score on the Y axis (strict CQRS: 4/15; Clean Architecture: 4/15; Data on the Inside: 5/15) are also the ones that keep the thinnest domains when applied with discipline. The proposals with the highest score (Service Layer and Active Record: 13/15 both) tend to produce variable domains because their flexibility permits it.

BCA occupies an intermediate position (9/15) that the thesis defends as pragmatically optimal in enterprise contexts with legacy systems and agentic capabilities under incorporation: firm enough at the frontier of the domain to preserve its thinness, flexible enough in the internal implementation to coexist with purchased software, legacy process engines, and agents of a statistical nature over which one has no traditional architectural control.

Application case · Activating a new customer’s broadband service

To make the three layers and the distribution of responsibilities tangible — including the seventh separation Procedural / Agentic — consider a case from the telecommunications domain: activating a new customer’s broadband service. It is a workflow representative of everyday operations under the TM Forum ODA framework⁵⁰ that touches both the own domain (customer, service, subscription) and foreign domains (network provisioning OSS, external billing, email provider), and that is enriched in the current era by the incorporation of a conversational assistant that supports the call-center agent and an automated content generator for the communication to the customer.

The distribution of the actions across BCA’s cells is as follows:

Five observations follow from this distribution. First, most of the behavior lives in Business Logic, distributed between Procedural and Agentic. Only four of the fifteen actions touch the own domain, and two touch the foreign domain; the remaining nine live in Layer 2 or in Presentation. The Agentic era adds nature to the behavior of Layer 2 without touching the core of the domain. Second, Procedural and Agentic coexist naturally in the same layer: the two agentic actions are not isolated in a special layer nor treated as exceptional cases — they are full citizens of Business Logic, interleaved with the procedural actions according to the logic of the workflow. Third, the agentic actions do not touch the domain: they operate exclusively in Business Logic, take domain information as input and produce output that returns to Layer 2 or Layer 1, but never directly modify the authoritative state of the SOR. It is the operational materialization of the thesis: the invariants of the domain stay protected from agentic volatility because the frontier between Layers 2 and 3 is respected strictly. Fourth, the two communication paths coexist naturally: the synchronous actions use the synchronous cells of each box, the asynchronous actions use the asynchronous cells, and no workflow is obliged to use one path or the other exclusively⁵¹. Fifth, the core of the domain stays intact and thin: the four actions marked with SOR are precisely what the thesis identifies as the authoritative core — invariants and persistence, with their asynchronous counterparts. All the volatile logic — whether procedural or agentic — lives outside the domain.

Architectural implications

Adopting BCA has specific implications for the design of enterprise components in the Agentic era. Components that play the role of SOR should expose thin APIs centered on operations that preserve invariants, consistent with Young’s⁵² vision of the command side in CQRS. The procedural and agentic orchestration components should be explicit and separate; they should not be disguised as extensions of the domain. Persistence should be interchangeable without touching the domain logic. Integration components (Gateway, Proxies, Events, Hooks) should be treated as modelers of a foreign domain⁵³⁵⁴. Asynchronous components (Events, Streams, Hooks) should be treated as full citizens of the design with their own versioning logic, their own delivery semantics, and their own SLAs⁵⁵.

The placement of AI and autonomous-agent logic deserves specific attention. Intelligence and agent components — language-model-based orchestrators, recommenders, optimizers, expert systems — are by nature coordinating process logic. Their correct place in BCA is the Agentic box within Business Logic, not Domain. This preserves the stability of the SOR while allowing the agentic logic to evolve rapidly. The asynchronous leg of the domain (the Events, Streams, Hooks cells) is particularly useful for integrating agents: they can subscribe to domain events to react autonomously without coupling to the core of the SOR. The seventh separation within Business Logic also makes it possible to apply specific governance regimes to each type of component: deterministic testing versus dataset evaluation, line-by-line observability versus aggregate metrics, code-based auditing versus input/output auditing, evolution by refactoring versus evolution by retraining. These differentiated regimes are critical for maintaining traceability and regulatory compliance in systems that combine both types of behavior.

The coexistence of mutable state and event log is an explicit architectural decision of BCA. Mutable state and the event log coexist as complementary representations of the domain, not as substitutes. This places the proposal in an intermediate position between traditional systems — where only mutable state exists and events, if any, are emergent and not authoritative — and pure Event Sourcing — where the state is always reconstructed from the event log and the state is not authoritative, only derived. In BCA, the mutable state is the primary source of truth and the event log is an authoritative complement. The Change Data Capture technique discussed by Kleppmann⁵⁶ provides the concrete mechanism for keeping both representations synchronized.

Limitations of the model

BCA is one architectural position among several legitimate ones, not the only one. Canonical DDD⁵⁷⁵⁸ is a respectable architectural position with genuine merits, especially in domains where the business logic is very rich and benefits from being concentrated in domain objects. The choice between canonical DDD and BCA should be made case by case, considering the context. The chapter’s thesis holds that in the Agentic era BCA produces better results, but this claim does not extend universally to all contexts.

The frontier of the domain is not always crisp in practice. As Fowler⁵⁹ acknowledges, the distinction between domain logic and application logic gets messy in real systems. There will be ambiguous cases where it is not clear whether a validation is intrinsic to the domain or is business policy. The recommended operative criterion is temporal in nature — if the rule can change through a commercial decision without altering the fundamental business model, it goes in Business Logic; if the rule is structural to the domain, it goes in SOR · Logic — but this criterion does not eliminate the ambiguity: it makes it discussable and resolvable case by case.

The frontier between Procedural and Agentic can blur. A specific limitation of the current era is that the separation between Procedural and Agentic components is not always crisp. A classic BRMS can incorporate heuristic rules with statistical properties; a modern agent can operate within a rigid procedural workflow. The seventh separation captures a fundamental distinction — explicit origin versus contextual derivation of behavior — but its practical application requires judgment in borderline cases, particularly in hybrid systems that combine symbolic reasoning with statistical inference.

BCA does not replace other frameworks. This decomposition is complementary, not substitutive, of other frameworks: TM Forum ODA⁶⁰ for functional classification at the level of a systems inventory, cloud-native principles for deployment, integration patterns such as those cataloged by Hohpe and Woolf⁶¹ for communication between components, and the Agentive Architecture framework of the Agentive World (Chapter 4) for systems that have crossed the Nadella Line. BCA applies to the interior of a component or set of components that operate in the pre-agentive state.

And the scoring model of the previous section has three acknowledged limitations. First, the scores reflect the author’s interpretations of each proposal’s texts; an evaluator with access to the same sources may arrive at different scores, especially in dimensions such as D2 and D3 that require judgment about the spirit of the texts. Second, the simple sum of the five dimensions implicitly assumes that they carry equal weight, which is a simplification; in some contexts D5 (compatibility with legacy) may weigh more than D4 (focus), and vice versa. Third, the model evaluates the stance of the original author, not the effective practice of the communities that adopt each proposal.

Mapping to the Agentive World

So far we have described the cartography of the pre-agentive state. The operative question this book poses — and which justifies BCA’s presence in it — is the question of the bridge: when an organization crosses the Nadella Line, what happens to each of BCA’s cells? Which migrate to the Agentive World and transform into something different? Which remain as invisible backend infrastructure? Which disappear?

The answer is not uniform across cells. The crossing affects each one differently, at different moments, with different consequences. What follows is the cell-by-cell mapping — the piece that turns BCA into an instrument of migration, not a mere description of the past.

Four general patterns emerge from the mapping. First, Layer 3 survives almost intact. The structural invariants and authoritative persistence are what the enterprise system has to preserve during the crossing, and the discipline of the thinness of the domain is what ensures they survive. BCA’s Layer 3 is, to a large extent, what becomes the substrate of the AgencyDomains of Chapter 4. Second, Layer 2 transforms profoundly. The Procedural box contracts; the Agentic box expands until it dominates; both eventually cease to be parallel boxes and become Botlets that compose behavior from the catalog of Capabilities. BCA’s seventh separation is the initial crack through which the Agentive World enters the enterprise system; over time, that crack widens until it consumes the entire layer. Third, Layer 1 bifurcates. The UI empties and eventually disappears as the primary interface; the API intensifies and transforms into a Connector (Layer 4), not a Capability. The transformation is asymmetric: one of the two boxes of Layer 1 dies; the other thrives under a different name. Fourth, Trust Infrastructure appears as a new cross-cutting concern that was not materialized in BCA. Governance, auditability, and identity and access policies, which in BCA were responsibilities dispersed across the cells, are elevated into an explicit cross-cutting layer in the Agentive World. This is one of the architectural contributions of Chapter 4: making visible what in the pre-agentive era remained implicit in each component.

The mapping also makes it possible to answer operative questions that an architect in transition asks daily. Do I have to rewrite my SOR to enter the Agentive World? No: Layer 3 survives. What you have to do is expose it with discipline via Capabilities. Do my current workflows die? Not all of them: those with regulatory traceability requirements survive; the rest are reabsorbed into Botlets. Are my current APIs useful? Yes, but their contract has to be renegotiated as a Connector (Layer 4), discoverable and governed by Trust Infrastructure. Do my applications with UI die? The ones that existed to navigate and filter information, yes. The ones that produce specialized artifacts survive longer, eventually with a copilot or agent as mediator, as we already described in Chapter 2.

Closing · The frontier of BCA

BCA is the architecture of the pre-agentive state. Its value in this book is twofold. First, it offers a formal cartography of what most of the organizations that will cross the Nadella Line have today: three layers, seven separations, a thin core, a dual orchestration between Procedural and Agentic. Second, and more important, it offers the mapping instrument that makes it possible to reason in a disciplined way about what migrates, what disappears, what remains — and why.

But BCA has an explicit frontier. When an organization crosses the Nadella Line and enters the Agentive World fully, the separations that BCA articulates tend to collapse. Layer 1 becomes a conversation with an agent. The distinction between Procedural and Agentic dissolves because the first box empties progressively. Eventually, even the frontier between Business Logic and Domain becomes mediated by an agentic entity that decides which steps to invoke. At that point, BCA has fulfilled its transitional purpose and yields the floor to a different architectural framework — a framework no longer organized around the separation between domain and orchestration, but around the four layers of the Agentive World: Interaction, Cognition, Autonomy, and Access.

That framework is the one Chapter 4 develops. It does so on the foundation that BCA has just established: we know what we had before, we know what migrates, we know what remains. Now we can describe, with the calm the change deserves, the architecture of the side we are heading toward.