How should an entity that abstracts an external service do its operations?

Question

I'm creating a system using some DDD principles and I'm stuck with a problem.

To give a bit more of context on what I'm trying to do, let me first describe what the system is about:

The ideia is to allow an user of an specific kind of service to be able to integrate and test many of these services without integrating his system with all of them.

To do that the user would integrate with my system, which acts as a gateway, integrating with all those services.

Now let me explain the problem:

For every service that is integrated there is an API implementation that is very specific (some use JSON, others XML) and for that reason these implementations are used as separated dependencies (projects).

In the domain layer, there is an entity named ExternalService, this entity represents a service integration that is supported.

Lets say the kind of service we are talking about here is a SMS system that sends messages to a phone number.

So we have an api implementation that integrates with the external service:

class XYZSMSProviderApi {
    public void sendMessage(String phone) {...}
}

And we have the entity ExternalService with the XYZ service data (this data is persisted in a database):

class ExternalService {
    public String name = "XYZ";
}

The problem is, who should be responsible for calling the sendMessage method of the XYZSMSProviderApi class?

Should I inject the API object in the entity and then have a method to do the actual message sending in the entity?

Answer 1

Should I inject the API object in the entity and then have a method to do the actual message sending in the entity?

Probably not. The usual idiom is that the domain model is responsible for the integrity of its own state/data, and nothing else. Integration with external services is an application concern, not a domain concern.

In DDD terms, if ExternalService("XYZ") is an aggregate in the domain, then the code within that entity is primarily about the business invariant that is to be enforced by that piece of the domain. Other concerns - which is to say, what do you do with the data now that you can be sure that it satisfies all of your business rules - live somewhere else.

So the application queries the aggregate to get the state that it needs, and the actual message sending would be in the application itself.

Answer 2

Beware of the saying "If all you have is a hammer, everything looks like a nail". Are you sure DDD is the right fit for your system? From the description of your context:

The ideia is to allow an user of an specific kind of service to be able to integrate and test many of these services without integrating his system with all of them.

To do that the user would integrate with my system, which acts as a gateway, integrating with all those services.

It looks like the domain of your application is actually very slim, or at least not very relatable with usual fits for DDD. DDD aims to support the development of medium to large enterprise software, with lots of complex business rules that must be mapped to the many administrative and operational processes of the company (and many other areas), defining the domain as the central abstractions common to the overall system (where the entities come in play).

I think you can look into other architectural models that are more about integrating external components rather than one which is focused heavily on abstractions over large business domains. One such model is to follow a plugin architecture, which basically means to design pluggable APIs (an interface in Java, for instance) and allow their implementations to be added and/or replaced at runtime or application boot-up (there is some generally useful information about it on this question and its references). Also, you can read about other models mentioned in this blog post; they are also generally aimed at bigger domains, but they describe nicely decoupled ways to deal with external dependencies which I believe will be useful to you.