Front-End-Aligned or Experience-Aligned Boundaries

Experience-aligned boundaries shape part of the architecture around a major user journey, client type, or interaction channel rather than around a deep domain model alone. The classic example is a backend-for-frontend layer that serves web, mobile, or partner experiences differently. This pattern can be useful because different experiences often need different aggregation logic, response shapes, caching strategies, and release cadence.

The important limit is that experience alignment should usually sit at the integration edge, not replace the domain model underneath. When teams misapply the pattern, they end up with service-per-screen decomposition, duplicated business logic, and unstable ownership that changes every time the product interface changes.

    flowchart LR
	    W["Web app"] --> BFF["Web experience layer"]
	    M["Mobile app"] --> MFF["Mobile experience layer"]
	    BFF --> C["Catalog domain service"]
	    BFF --> P["Pricing domain service"]
	    BFF --> O["Ordering domain service"]
	    MFF --> C
	    MFF --> P
	    MFF --> O

What to notice:

• the experience layer sits between the client and domain services
• the pattern is about integration shape and channel needs
• the domain services still own core rules and authoritative data

When This Pattern Works Well

Experience-aligned boundaries are strongest when:

• one channel needs tailored aggregation or composition
• response shapes differ significantly by client type
• one journey needs rapid iteration without changing the core domain services
• the edge layer can remain thin in domain ownership

For example:

• a mobile app may need compact aggregated responses
• a partner API may need a different contract style and authorization model
• a web checkout flow may need user-journey-specific orchestration

In those cases, an experience-aligned layer can reduce churn in core services while giving frontend-facing teams more focused control over the integration surface.

What This Pattern Is Not

This pattern is not:

• one service per screen
• one service per frontend team regardless of domain
• a way to duplicate business rules in every client-facing service
• an excuse to bypass clear domain ownership

That distinction matters. A backend-for-frontend can be healthy. A screen-driven service map usually is not.

Keep Domain Ownership in the Domain

The strongest design uses experience-aligned layers to:

• aggregate calls
• transform payloads
• apply channel-specific policies
• support client-specific caching or composition

It should not use them to:

• redefine domain rules
• own authoritative business data
• become the permanent home of pricing, entitlement, or order policy

If the experience layer becomes the place where the real business logic lives, then the domain boundary has weakened.

A Small Configuration Example

One way to keep the layer honest is to document what it owns:

 1service: mobile-commerce-bff
 2owns:
 3  - response_aggregation
 4  - channel_specific_auth_checks
 5  - mobile_payload_shaping
 6does_not_own:
 7  - pricing_rules
 8  - order_state_authority
 9  - inventory_policy
10depends_on:
11  - catalog
12  - pricing
13  - ordering

What this demonstrates:

• the experience layer has a real responsibility
• its responsibility is bounded
• core domain logic remains elsewhere

This kind of clarity helps prevent drift from experience shaping into accidental domain ownership.

When the Pattern Becomes Dangerous

The pattern becomes risky when:

• each screen or page becomes a service
• the same business rule is reimplemented in several experience services
• domain services are reduced to dumb data providers for UI layers
• the product structure changes faster than the architecture can absorb

At that point, the system is no longer using an experience-aligned boundary. It is letting the user interface dictate decomposition.

Experience Alignment and Ownership

Ownership should still be explicit. A frontend-aligned team may reasonably own the experience layer, but it should coordinate with domain teams through clear contracts. If the experience team must constantly modify domain logic to ship features, then the layer is probably too thick or the domain services are too thin.

Design Review Question

A company wants one service for each major screen in its mobile app so every mobile squad can deploy independently. The proposed services would also contain pricing rules, availability checks, and discount eligibility logic. What is the main architectural problem?

The main problem is that the team is confusing experience alignment with UI-driven domain ownership. An experience layer can be a healthy integration surface, but if each screen becomes the home of core business rules, the architecture will duplicate logic, fragment domain ownership, and become unstable whenever the product design changes.

Quiz Time