Domain Services vs Repositories when backed by a remote service

Question

I'm building a DDD application which is effectively a wrapper around Cognito. As such, everything that this is doing is effectively just a call onto the Cognito SDK.

Where I'm getting confused is how this should work with respect to Domain Services or Repositories.

I've got an Aggregate to represent a User. I then have a number of actions that I want to be able to support:

• Load a user by ID
• Update a user
• Delete a user
• Send an email confirmation message
• Verify the users email address
• Configure MFA
• Verify an MFA code
• Change the users password

Now, the first three of these feel like they fit a Repository well. They're basically Retrieve, Update and Delete from the standard CRUD model.

However, the other five I'm less sure about. They are actions performed on the user, but they're not standard CRUD ones. However, all eight of these are done using the same SDK instance.

So, would it be better to:

• Put all of these in a Repository?
• Put all of these - even the CRUD ones - in Domain Services?
• Put some of these on a Repository and others on Domain Services? (Even though they're all backed by the same SDK instance)
• Put some of these on a Repository and others on the Aggregate? (Though this would then mean that the Aggregate has calls that affect a remote service, which seems bad)
• Something else entirely?

To add to this, the "Verify an MFA Code" action is needed as a step in some other actions - namely "Delete a user" and "Change the users password". Which definitely makes it feel like a Domain Service.

Cheers

Answer 1

In Domain-Driven Design, Repositories are responsible for persisting and retrieving Aggregates, while Domain Services are responsible for encapsulating business logic that does not naturally fit within the Aggregate's boundaries. Given that all of the actions you've listed involve interacting with a remote service, it may make sense to create a CognitoService or similar class to handle these operations. This could be injected into your User Repository as a dependency, allowing you to keep your CRUD operations separate from your non-standard actions.

Regarding the "Verify an MFA Code" action, it seems like this would be better placed in the CognitoService rather than the Domain Service or the Aggregate, as it is closely tied to the Cognito SDK.

In summary, you could create a User Repository that handles the standard CRUD operations and relies on a CognitoService to handle the non-standard actions that interact with the Cognito SDK. This would allow you to keep your concerns separate and adhere to the Single Responsibility Principle.

Answer 2

From the perspective of your domain/business logic, how is a remote API different from a database server? We could arguably cast this net even wider and ask the same question for any kind of input/output that is not generated by your domain/business logic itself.

Other than the concrete implementation to communicate with it, there is no difference. It functions the same way. In either case, you're dealing with a resource that is not under your control, and you are firing requests at it and parsing its response (if any response is given).

Whether you call it a repository or a service is a nomenclature distinction, not a technical one. That being said, this is not a definitive argument for lumping them together either. I'm just pointing out that the decision here is a subjective one based on what makes intuitive sense to us. On a technical level, it's all the same.

I would consider that the concrete implementation is best kept together, since it's using the same remote resource and there's some shared (private) logic that goes along with it.

However, an argument can be made to separate the interface between a repository (aggregate data storage) and service (logical operations).

Based on the question as asked, I think a single class which implements two distinct interfaces makes the most sense.

Answer 3

A repository, for instance, is an object with methods for retrieving domain objects from a data store (e.g. a database).

According to wikipedia Domain driven design page.

Between the lines everything that can take part in a transaction, or differently said everything that could be rolled back, should be placed in repository, everything else should be placed in service to make the difference clear and follow the principle of least astonishment¹ when working with transactions.

¹ _{a component of a system should behave in a way that most users will expect it to behave, and therefore not astonish or surprise users. Principle of least astonishment according to wikipedia.}