How to Include Third-Party Models in Your Domain Model

domain-driven-designdomain-model

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?

Best Answer

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.

Related Topic