I'm currently trying to design a little application using Domain Driven Design but I'm afraid I don't really get the concept yet. Let me try to explain this as clearly as possible.

public interface IMyDomainRepository
    void Add(IAnInterfaceFromAThirdParty element);

The interface above is defined in my domain model and this will be used in a different project called ThirdPartyImplementionVersionX.

Now IAnInterfaceFromAThirdParty is not defined in my domain model but comes from my third party library.

I could create a class/interface in my domain model which implements the same properties and methods as the interface IAnInterfaceFromAThirdParty but this interface has 20 methods defined thus making it a difficult task to implement the same logic.

Is this the way to go or am I missing something?

2 Answers 2


A third party component has its own model expressed in its own language. Moreover, generally the third party component addresses a general-purpose problem which is normally a portion of the more context-specific problem you are trying to solve.

The first thing to do is be aware that your model, and the third party one are different and form two separate bounded contexts. Once you've clarified that, you might choose the strategy you want to apply when dealing with the third party component:

  • Protect your model with an anti-corruption layer thus keeping your model physically separated from the third party, by putting an adapter-like structure in the middle. This allows for sophisticated modeling in your domain without compromising with the external model.
  • Adhere to the external model (the pattern here is known as conformist): not so much sophisticated modeling, but that might still be viable a conscious decision, in non-core portions of the system.

Don't try to do both: if you are looking for nice sophisticated modeling, you need to protect the borders of your domain, without leaking from external domains. In other words, the anti-corruption layer tends to be the preferred choice.

In the example you're bringing, this would probably end up in defining interfaces in terms of your domain language, and relying on the functionalities provided by the third-party component only at the implementation level.

  • But if I want to maintain the same functionality as the original model I need to map all properties of the model in my adapter-like structure from the third party model?
    – thomasvdb
    Feb 7, 2012 at 19:08
  • 1
    Do you need all the third-party model functionalities in your domain? Are they at the same level of abstraction of your domain? I am assuming (maybe I am wrong on that) that the third party is exposing general purpose or more technical properties. Your adapter should expose only those high level functionalities which are relevant for your domain, and invoke the third party to implement them. Only the adapter implementation depends upon the third party, not the interface.
    – ZioBrando
    Feb 8, 2012 at 14:31

When I am working with models from a third-party I usially create an Adapter and my own models. The Adapter should map the items from the third-party to my models.

The problem behind it is that a third-party-assemblie or something like that could allways change. What are you doing when you switch from a to b?!? CHanging all the lines where you have implemented the model from the third-party product?

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.