Domain Driven Design Context Mapping Created: 10 Jan 2026 Updated: 10 Jan 2026

Conformist

In Domain-Driven Design (DDD), Conformist is a strategic context mapping pattern that describes a specific relationship between an Upstream (the provider) and a Downstream (the consumer) Bounded Context.

In this relationship, the Downstream team chooses—or is forced—to conform to the Upstream team’s domain model. Instead of creating an Anti-Corruption Layer (ACL) to translate the Upstream's terms into their own, the Downstream team uses the Upstream’s models, terms, and logic directly in their own context.

Why use the Conformist pattern?

The Conformist approach is typically adopted when:

  1. Upstream Power: The Upstream team is very powerful or "too big to care" (e.g., a massive legacy system, a huge internal platform, or a giant third-party API like Amazon or Google). They won't change their model for you.
  2. Resource Constraints: The Downstream team doesn't have the time or budget to build and maintain a complex Anti-Corruption Layer.
  3. Model Compatibility: The Upstream’s model is actually "good enough" or very close to what the Downstream needs anyway.

Comparison: OHS vs. Conformist

While the Open Host Service (OHS) pattern focuses on the provider making life easier for consumers, Conformist focuses on the consumer surrendering to the provider's model.

FeatureOpen Host Service (OHS)Conformist
ControlUpstream provides a stable, public contract.Upstream dictates the model; Downstream follows.
ComplexityHigher for Upstream (must maintain the API).Higher for Downstream (must adapt to Upstream's changes).
Domain PurityHigh. Downstream maintains its own language.Low. Downstream's model is "polluted" by Upstream.
Best ForStrategic core services with many consumers.Integrating with unchangeable or dominant systems.

Cinema Ticketing Example: The Payment Gateway

Imagine your Booking Context (Downstream) needs to integrate with a global Payment Provider like Stripe (Upstream).

Stripe has its own Ubiquitous Language: Charge, Source, Refund, and IdempotencyKey.

  1. If you act as a Conformist: You don't create your own Payment entity. Instead, you use Stripe's Charge object throughout your Booking logic. If Stripe changes their SDK or their logic, your Booking code might break because you are tightly coupled to their model.
  2. If you used an ACL: You would map Stripe's Charge to your own internal CinemaPayment object.

Code Implementation (.NET Core)

In a Conformist relationship, the Downstream project often adds a direct reference to the Upstream's library or SDK and uses those classes inside its own Service layer.

// Cinema.Modules.Booking (The Downstream)
using ExternalPaymentProvider.SDK; // Directly conforming to the Upstream's SDK

namespace Cinema.Modules.Booking.Application;

public class ReservationService
{
public async Task CompleteBooking(Guid bookingId)
{
// We are NOT using our own "Payment" model.
// We are CONFORMING to the external "ChargeRequest" model.
var chargeRequest = new ChargeRequest
{
Amount = 5000,
Currency = "USD",
Description = $"Booking {bookingId}"
};

// If the External SDK changes the 'Amount' from int to decimal,
// our code breaks immediately because we are a Conformist.
var result = await PaymentProvider.Process(chargeRequest);
}
}

Summary of the "Trade-off"

The Conformist pattern is a pragmatic choice. It saves development time upfront (no translation logic needed), but it introduces a high risk of technical debt because any change in the Upstream system ripples directly into your Downstream business logic.

Would you like to see how to transition from a "Conformist" approach to an "Anti-Corruption Layer" (ACL) as a system grows?

Share this lesson:

Details

Category
Domain Driven Design
Sub: Context Mapping
View All Courses Back to Lessons

Navigation

Progress 3 / 7
Start 43% Complete
Published Language Anti-Corruption Layer (ACL)
Statistics
7 Lessons in Context Mapping
1 SubCategories in Domain Driven Design
7 Total Lessons in Domain Driven Design