I'm getting ready to create an integration with a major external system and was wondering if my understanding of the design pattern for this in domain driven design was solid.

Considerations: External System serves SOAP, mine's a web api 2 solution.
Full CRUD operations across many SOAP methods

My thoughts:

  1. Create a giant facade class that receives the data.
  2. Have each method in the facade call an adapter that then transforms the data from SOAP to a domain model.
  3. Call the adapter in infrastructure service class and pass it up into the domain.

Concerns: Does this pattern sound correct? Is there a more fitting one for creating a clearly defined bounded context?

I'd be using infrastructure as a pass through to the domain, it wouldn't be doing much at this point, another option is to pass the adapter directly to a factory though I prefer going through infrastructure.

Conceptual Diagram I'm basing my design on:

Domain-Driven Design: Tackling Complexity in the Heart of Software By Eric Evans

  • 4
    What do you mean by "correct?" The "correct" approach is the one that best meets your specific requirements. Does this approach best meet your specific requirements? What prevents you from simply using the existing API as-is? Commented Aug 22, 2017 at 19:47
  • @Robert yeah, I realize there's no "correct" way to architecture, on the flip side, there's best practices for implementing patterns, thereby it is safe to infer something like: "Does this design make sense?" See OP considerations for why I'm hesitant to use the API as-is.
    – RandomUs1r
    Commented Aug 22, 2017 at 20:12
  • You do't necessarily need everything in that diagram. The diagram is merely illustrative. Commented Aug 22, 2017 at 20:53
  • 1
    My question is why are you looking for someone (strange) say to you seems fine to me go ahead?. Reading the question I come to the conclusion that you are not looking for answers, you are looking for aproval (IMO). What is really concern you?
    – Laiv
    Commented Aug 22, 2017 at 22:11
  • 1
    One thing I'd point out is to make sure that your subsystem doesn't depend on the anticorruption layer (the arrows should point the other way), otherwise you still end up with a strong dependency on the other subsystem. The way to do that is to have your system define ServiceA & ServiceB interfaces as suitable abastractions, and then have the AC layer implement them, so that your subsystem has no idea about the AC layer. Commented Aug 23, 2017 at 6:44

1 Answer 1


An Anti-corruption layer is a class/ package/component that take as an input the external model and it produces the local model.

For example, in a CQRS architecture, it can be implemented as a Saga: would take the events generated by the aggregates in the external bounded context and would create commands for aggregates in the local bounded context.

  • That makes sense, so I'll stand up a project for it and have it talk to the domain via interfaces, your Saga is my facade I believe, the adapters / translators seem to be optional.
    – RandomUs1r
    Commented Aug 23, 2017 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.