Your Feature Store Is a Domain Boundary

⏱ 20 min read

There’s a particular kind of enterprise mistake that looks sophisticated from a distance. It has Kafka topics. It has a low-latency serving layer. It has offline and online consistency checks. It has a platform team with a roadmap. And yet, underneath all that polish, it commits a very old sin: it treats meaning as an implementation detail. event-driven architecture patterns

That, in practice, is what many feature stores become.

They are introduced to solve a legitimate problem—reuse feature computation, standardize training-serving parity, reduce duplicated pipelines, centralize discovery. All good goals. But then the center of gravity shifts. The feature store stops being a supporting capability and starts behaving like the place where business facts are defined. Fraud risk, customer tenure, active subscription, merchant quality, borrower affordability—concepts with domain meaning get flattened into “features.” Ownership blurs. Semantics leak. Upstream services become raw material providers to a machine learning platform that is now quietly making business definitions on their behalf.

This is where architecture matters. Not in the diagrams. In the boundaries.

A feature store is not just a data product. It is a line of force in your ownership topology. If you place it carelessly, it will pull logic out of domains, centralize decisions that should remain federated, and create a shadow model of the business that nobody explicitly designed. The result is familiar to anyone who has lived through large-scale enterprise data programs: one more “golden” layer that becomes politically important, technically hard to change, and semantically unreliable.

My argument is simple and opinionated: your feature store should be treated as a domain boundary, not as a universal semantic clearinghouse.

That sounds subtle. It isn’t. It changes who owns feature definitions, where reconciliation happens, how Kafka streams are partitioned, how microservices publish facts, how migration unfolds, and what kinds of failures you expect. It also tells you when not to use a feature store at all. microservices architecture diagrams

The difference between a useful feature platform and a semantic tar pit is usually not technology. It is whether the architecture respects domain-driven design.

Context

Feature stores emerged because machine learning in enterprises tends to repeat the same sins as integration middleware before it. Teams compute the same aggregates in five places. Batch pipelines drift from online APIs. Data scientists train on one definition of “active customer” while the production service uses another. A recommendation model reads from a warehouse snapshot while the serving stack recomputes on clickstream events. Everyone says “single source of truth,” but what they actually have is a museum of near-truths.

The feature store promises order. A registry for features. Shared computation. Point-in-time correctness. Offline training sets. Online low-latency lookups. Governance. Discovery. Sometimes materialization into Redis or Cassandra. Sometimes Kafka-native stream processing. Sometimes a warehouse-first design with periodic sync to online serving. EA governance checklist

All of this is useful. None of it answers the ownership question.

In a healthy enterprise architecture, domain services own business facts inside clear bounded contexts. Billing owns invoice state. Identity owns customer verification status. Risk owns adjudicated risk outcomes. Orders owns order lifecycle. Marketing does not get to redefine “active account” because it needs a campaign segmentation shortcut. Data science does not get to redefine “merchant fraud exposure” because the source services are inconvenient. A feature store can expose, derive, and package these facts for models—but the semantics still belong somewhere.

This is the key point many organizations miss: features are not merely transformations; they are claims about the business.

Some claims are thin and local: “count of logins in the last seven days.” Fine. Some are loaded: “creditworthy customer,” “eligible subscriber,” “engaged patient,” “fraudulent merchant.” Those are not technical columns. They are domain concepts with policies, edge cases, exceptions, audit implications, and often legal consequences.

Once you see that, the architecture stops being a data plumbing exercise. It becomes a question of domain boundaries and ownership topology.

Problem

The failure pattern usually starts innocently.

A central ML platform team builds a feature store to accelerate experimentation. Product teams contribute event streams and database snapshots. The registry grows. Reusable features are celebrated. Duplicated SQL is eliminated. Then teams begin to depend on centrally curated features because it is easier than understanding the source domains.

That convenience is expensive.

Soon you find multiple categories of semantic drift:

• A feature named customer_tenure_days is calculated from account creation timestamp in one use case, from first funded transaction in another, and from completed onboarding in a third.
• active_subscription means “billing status = paid” to Finance, “currently entitled to service” to Product, and “not churned in the model lookback window” to Data Science.
• Fraud models consume chargeback_rate_90d, but the definition of chargeback reverses when Payment Operations changes reconciliation rules.
• Eligibility features quietly encode policy decisions that should have remained in an underwriting or rules domain.

The central feature store becomes a semantic blender.

Worse, its consumers are often downstream enough that they cannot challenge the definitions. They trust the registry because the registry looks official. A bad architecture gains legitimacy by being well documented.

There is another problem, more technical but just as corrosive: the feature store often straddles both analytical and operational worlds without clean contracts. It ingests Kafka events from microservices, joins them with warehouse dimensions, computes stream-time and batch-time versions of similar entities, and then serves them to low-latency applications. When values disagree, teams call it “eventual consistency.” Usually it is not. Usually it is unresolved ownership.

If one service owns customer verification and another emits an event stream about document review, who decides what is_verified means in the feature store? If the warehouse backfill disagrees with the stream-derived online state, where is reconciliation logic supposed to live? In the platform? In the domain? In a data quality rule? The wrong answer is “wherever it is easiest.”

That wrong answer is common.

Forces

Several forces push enterprises toward the wrong design.

1. Reuse pressure

Feature engineering is expensive, and teams hate recomputing the same aggregates. Reuse pressure naturally creates centralization pressure.

2. Latency pressure

Online inference needs fast lookups. The easiest path is to materialize precomputed features into a serving store and standardize access. The serving layer then starts looking operationally important, which tempts people to move more business logic into it.

3. Training-serving parity

This is a real need. If training uses warehouse logic and serving uses service APIs or stream processors, drift is almost guaranteed. Teams want one place to define features so both worlds align.

4. Organizational asymmetry

Platform teams are often better staffed to build robust pipelines than domain teams are to expose clean, versioned business facts. So the platform absorbs semantic work by default.

5. Data gravity

Once historical data, stream processing, and discoverability all converge in one platform, it becomes politically difficult to argue that business definitions should remain distributed.

6. Audit and compliance

Regulated environments want traceability. Centralization looks safer. Sometimes it is safer. Sometimes it simply centralizes errors.

These forces are not imaginary. The architecture has to respect them. A sermon about pure bounded contexts is useless if your fraud model needs a sub-20ms feature lookup and your domain services can’t provide one. What matters is not pretending these forces disappear. What matters is deciding where semantics live and where packaging happens.

That is the trade.

Solution

Treat the feature store as a domain-aligned projection and serving platform, not as the canonical owner of business meaning.

That phrase does a lot of work.

A feature store should package domain facts into model-ready representations. It may derive aggregates, normalize values, compute temporal windows, and materialize online serving views. But the semantics of the underlying business concepts should remain owned by the bounded contexts that define them. The feature store is allowed to compose. It is not allowed to annex.

In domain-driven design terms:

• Bounded contexts own the language and invariants.
• The feature store publishes projections optimized for ML and decisioning.
• Cross-domain features are compositions across context maps, not excuses to erase them.

This means your ownership topology should reflect at least three layers:

1. Domain fact ownership

Microservices or domain data products publish authoritative business facts and events.

1. Feature computation ownership

Feature pipelines transform those facts into reusable features, but with explicit lineage to source domains and versioned semantics.

1. Serving ownership

Online and offline stores serve low-latency and training use cases, but they do not become the source of truth for domain state.

The strongest pattern I’ve seen is to organize features by domain-owned namespaces with explicit contracts. Not one giant feature catalog, but a federated catalog with platform support.

For example:

• identity.verified_status.v2
• billing.days_since_last_successful_payment.v1
• orders.completed_orders_30d.v3
• risk.merchant_chargeback_rate_90d.v2

Even derived cross-domain features should make their dependencies explicit:

• growth.customer_value_segment.v1 depends on billing, orders, and crm
• fraud.synthetic_identity_risk_score.v4 depends on identity, payments, and device

This naming is not bureaucracy. It tells the truth about ownership.

A practical semantic rule

If a feature encodes a domain policy, the owning domain must approve and version it.

If a feature is a technical aggregate over already-defined facts, the feature platform may own the implementation.

That one rule saves a lot of pain.

Architecture

A healthy feature store architecture in an enterprise usually looks less centralized than the vendor demos and more disciplined than the average internal platform.

The picture is simple. The semantics are not.

Domain publication

Each bounded context publishes one or both of:

• Domain events for state changes with business meaning
• Reference tables or CDC feeds for slowly changing or transactional state

Kafka is often the right backbone here because it preserves ordered event histories well enough for stream processing and replay. But Kafka does not solve semantics. It only preserves what you emit. If your topics contain leaky technical events rather than domain facts, you will create a very elegant mess.

A good topic says CustomerVerificationStatusChanged.

A bad one says customer_table_updated.

One gives downstream consumers language. The other gives them archaeology.

Feature pipelines

Feature pipelines consume domain facts and transform them into:

• point-in-time correct training datasets
• online feature values
• historical backfills
• lineage metadata and quality checks

This is where batch/stream duality matters. Some features are naturally event-driven and should be computed in Kafka Streams, Flink, or similar. Others are warehouse-native and cheap to compute in batch. Many enterprises need both.

The trick is not insisting on one computation style. The trick is keeping one semantic definition.

A feature may have:

• a streaming implementation for online serving
• a batch implementation for backfill and training
• a reconciliation process to detect divergence

Same definition. Multiple runtimes.

Registry and contracts

The feature registry should store more than schema. It should store:

• owning domain
• semantic description
• policy classification
• freshness expectation
• point-in-time join rules
• source lineage
• versions and deprecation status
• reconciliation tolerances between online and offline paths

That registry is a context map, not just a catalog.

Online serving

The online store exists to reduce latency, not to become a hidden transaction system. Keep that sentence on the wall.

If your online feature store starts being used as the fastest place to ask “what is the customer’s current state?”, you’ve already started to lose the boundary. The current state still belongs to the operational domain service. The online feature store serves model-oriented projections of that state, often lagging, often denormalized, often windowed.

Those are different things.

Reconciliation

Every serious feature platform eventually needs reconciliation because batch and stream pipelines drift, events arrive late, source systems backfill history, and domain corrections happen out of band.

This is not an edge case. It is table stakes.

A robust architecture includes:

• replay from Kafka or immutable logs
• batch reconstitution from authoritative stores
• diff checks between online and offline materializations
• compensating updates when late or corrected events change feature values
• traceability to the domain fact versions used at scoring time

Without reconciliation, your “feature consistency” claims are mostly marketing.

Migration Strategy

No enterprise gets to the right architecture by decree. You get there by strangling the wrong one.

The usual starting point is a centralized feature platform already doing too much semantic work. You cannot just “move ownership to domains” if the domains have no event contracts, no quality practices, and no staff for data product responsibilities. Architecture is not wishful thinking with swimlanes.

A progressive strangler migration works better.

Step 1: Inventory semantic hotspots

Identify features that are not just aggregates but domain assertions:

• eligibility
• verification
• churn state
• fraud labels
• account health
• entitlement status
• affordability

These are the dangerous ones. They deserve explicit domain ownership first.

Step 2: Classify feature ownership

Create three classes:

• Domain-owned features: encode business meaning or policy
• Platform-owned technical features: windows, counts, rates, normalizations over established facts
• Composite features: combine multiple domain-owned inputs for a specific modeling purpose

This classification immediately reduces ambiguity.

Step 3: Introduce source contracts

For semantic hotspots, define authoritative domain facts and publish them through APIs, CDC, or Kafka topics. Version the contracts. Put real language around them. Add examples and edge cases. This is domain-driven design in practical clothing.

Step 4: Build parallel pipelines

Run old centralized feature definitions and new domain-aligned definitions in parallel. Compare outputs. Expect disagreement. That disagreement is useful; it reveals where the old platform had been inventing semantics.

Step 5: Add reconciliation loops

Before cutover, build automated checks:

• parity thresholds
• temporal drift analysis
• late-event impact analysis
• model score sensitivity to feature divergence

Do not migrate blind. Some differences matter less than others.

Step 6: Cut over by bounded context

Move one semantic cluster at a time:

• identity-related features
• billing-related features
• order lifecycle features
• risk adjudication features

Avoid a “big rename and replatform.” It will fail politically before it fails technically.

Step 7: Deprecate central semantic definitions

This is the part many firms skip. They add new contracts but keep old centrally-defined features alive forever. Then consumers continue using them because migration is annoying. Set deprecation dates. Remove discoverability. Break the habit.

Here’s the topology shift you want:

Migration is successful when the feature store becomes thinner in semantics and stronger in operational excellence.

That sounds backwards to central platform teams. It isn’t. Thin semantics is what allows thick reliability.

Enterprise Example

Consider a global retail bank building a unified feature platform for fraud detection, credit risk, and next-best-action marketing. It has hundreds of microservices, Kafka as the event backbone, a warehouse lakehouse for analytics, and several model-serving applications.

At first, the bank centralizes aggressively. The feature team defines:

• customer tenure
• verified customer
• delinquency status
• active cardholder
• merchant trust score
• income stability
• affordability band

The platform is fast. It is also wrong in all the ways that matter.

Why? Because those concepts span different bounded contexts:

• Identity owns customer verification and KYC state
• Cards owns card lifecycle and activation semantics
• Collections owns delinquency classifications
• Merchant Risk owns adjudicated merchant trust outcomes
• Underwriting owns affordability policy and overrides

The central feature team computes some of these from raw transaction tables and event traces because that’s easier than coordinating with five domain teams. Then the trouble starts.

Marketing uses active_cardholder to target campaigns. Fraud uses the same feature to suppress verification prompts. Cards changes its activation policy for digital wallets. Suddenly model behavior shifts, campaign eligibility changes, and nobody can explain why. The feature store had encoded “active” as “at least one settled card transaction in 45 days.” Cards meant “card is activated and not blocked.” Both sounded reasonable. Only one was actually owned.

The bank fixes this over 18 months.

Identity starts publishing CustomerVerificationStatusChanged events with explicit reasons and effective timestamps. Cards publishes card entitlement and activation state as domain facts. Collections exposes delinquency buckets with policy version metadata. Underwriting refuses to let affordability become a reusable raw feature across all use cases; instead it publishes approved decision outputs and selected supporting facts under strict governance.

The feature store remains central as a platform, but the semantics are federated. Fraud still builds a synthetic_identity_risk_score, but it now depends on Identity-owned verification facts and Payments-owned transaction windows. Marketing still uses engagement features, but active_cardholder disappears in favor of Cards-owned card_entitlement_status and platform-owned usage aggregates.

What changed operationally?

• Online serving latency improved because fewer emergency semantic fixes were patched in the serving path.
• Auditability improved because feature lineage pointed back to domain contracts rather than opaque SQL transformations.
• Reconciliation became tractable because there was a place to resolve disputes: the owning domain.
• Migration slowed initial feature onboarding, but it sharply reduced downstream breakage.

The architecture got more political before it got better. That is normal. Boundaries are social technology.

Operational Considerations

Once you treat the feature store as a domain boundary, operations become clearer.

Freshness and SLA design

Not every feature needs the same freshness. Device fingerprint risk may need seconds. Customer income bracket may tolerate daily refresh. Publish freshness expectations with the feature contract and design serving paths accordingly.

Versioning

Feature versioning is not just schema versioning. It is semantic versioning:

• breaking change to meaning: new version
• implementation optimization with same semantics: same version, new lineage metadata
• new source domain contract: usually a new version unless semantics are provably identical

Point-in-time correctness

This remains non-negotiable for training data. If your offline feature generation can look into the future relative to the training label, your model metrics are theater.

Backfills and replay

Kafka replay and warehouse backfill must be built in from the start. Late corrections are normal in billing, fraud, underwriting, and healthcare domains. A platform that cannot reconstitute historical feature values will eventually become untrustworthy.

Governance

Governance should focus on semantic accountability and regulatory handling, not just field-level access control. Ask:

• who owns this meaning?
• what policy or business rule does it encode?
• can it be used across domains?
• what is the retention and explainability requirement?

Observability

Measure:

• feature freshness
• null rates and cardinality shifts
• online/offline divergence
• event lag
• source contract breakage
• model sensitivity to feature anomalies

A feature platform without observability is just a cache with a UI.

Tradeoffs

There is no free architecture here.

What you gain

• Clear ownership of business semantics
• Better explainability and auditability
• Lower semantic drift across ML and operational systems
• More resilient migration paths
• Less accidental centralization

What you pay

• Slower coordination across domain teams
• More upfront contract work
• Potential duplication of some feature logic across contexts
• Harder platform governance
• More nuanced registry and lineage management

This trade is worth it when feature values influence meaningful business decisions. It may not be worth it for lightweight experimentation or isolated recommendation systems with minimal policy load.

The mistake is assuming centralization is simpler. Centralization is simpler only at first. Then the interest compounds.

Failure Modes

A serious architecture article should name the ways this goes wrong.

1. The semantic black hole

The feature store becomes the de facto owner of every hard business definition because domain teams are slow or unavailable.

Result: platform bottleneck, weak accountability, model drift nobody can root-cause.

2. Topic theater

Teams publish Kafka events but they are technical change notifications, not domain facts.

Result: downstream feature logic reconstructs semantics from database noise. This is brittle and expensive.

3. Reconciliation as an afterthought

Online and offline values disagree, but there is no formal correction path.

Result: training-serving skew, silent score degradation, endless debugging folklore.

4. One registry to rule them all

The catalog pretends all features are equal and omits ownership, policy, and context metadata.

Result: discoverability without trust.

5. Serving-store capture

The online feature store becomes a read-optimized shadow operational database.

Result: consumers bypass source services, domain boundaries collapse, stale projections become business truth.

6. Composite feature confusion

Cross-domain features are treated as canonical facts.

Result: derived model inputs start masquerading as enterprise concepts.

The line is worth repeating: a feature can be reusable without being canonical.

When Not To Use

A feature store is not mandatory architecture. Sometimes it is an overreaction.

Do not use one, or do not use a large centralized one, when:

• You have a small number of models with local feature logic and little reuse.
• The domain semantics are still unstable and teams are learning what matters.
• Online inference is not latency sensitive.
• The main problem is poor source data quality rather than feature reuse.
• Your organization lacks the operational discipline for lineage, replay, and reconciliation.
• A simple warehouse with versioned transformation pipelines will do.

Also, do not use a feature store as a substitute for fixing domain APIs or event contracts. If source semantics are broken, the feature layer merely industrializes confusion.

Related Patterns

Several patterns sit close to this one.

Bounded Context

The core DDD pattern. Feature definitions should respect bounded contexts rather than dissolving them.

Published Language

Domain events and feature contracts need a shared language. Otherwise every downstream consumer invents translations.

Anti-Corruption Layer

Useful when a feature platform must consume legacy systems with poor semantics. Wrap the mess before it contaminates the registry.

CQRS Projections

Online feature stores are essentially specialized read projections. Treat them that way, with all the usual caveats about staleness and rebuildability.

Data Mesh, cautiously applied

A domain-oriented feature ownership model resembles data mesh ideas, but don’t get carried away. Not every domain team is ready to operate production-grade ML feature pipelines. Platform enablement still matters. enterprise architecture with ArchiMate

Strangler Fig Pattern

Essential for migration. Replace central semantic logic incrementally, not by proclamation.

Summary

A feature store is easy to describe in technical terms: registry, offline store, online store, pipelines, point-in-time joins, serving APIs. But those parts are not the architecture. The architecture is the ownership topology around them.

If the feature store becomes the place where business meaning is invented, you will build a polished semantic monoculture that is fast, useful, and fundamentally unstable. The first few quarters will look productive. Then definitions diverge, reconciliations fail, domains resent the platform, and regulators or auditors start asking who actually owns the meaning of the numbers driving decisions.

The better design is more disciplined and a little less glamorous. Let bounded contexts own business facts. Let the feature store project, compose, and serve them for ML and decisioning. Use Kafka and microservices where they help, but don’t confuse event transport with semantic clarity. Build reconciliation as a first-class capability. Migrate with a strangler strategy. Version meaning, not just schema. Keep the online store in its place.

Most of all, remember this: a feature is not just a column with a timestamp. It is a statement about the world.

And in enterprise architecture, statements about the world need an owner.

Frequently Asked Questions

What is enterprise architecture?

Enterprise architecture aligns strategy, business processes, applications, and technology in a coherent model. It enables impact analysis, portfolio rationalisation, governance, and transformation planning across the organisation.

How does ArchiMate support architecture practice?

ArchiMate provides a standard language connecting strategy, business operations, applications, and technology. It enables traceability from strategic goals through capabilities and services to infrastructure — making architecture decisions explicit and reviewable.

What tools support enterprise architecture modeling?

The main tools are Sparx Enterprise Architect (ArchiMate, UML, BPMN, SysML), Archi (free, ArchiMate-only), and BiZZdesign. Sparx EA is the most feature-rich, supporting concurrent repositories, automation, scripting, and Jira integration.