What creates an aggregate that isn't stored in a database?

Viewed 67

In my DDD design, a Command Handler is asked to create a conversation. This is done by calling a third party API.

I use conversation as an abstraction, as today it is a phone call, tomorrow could be something else. I will represent that conversation as a Conversation aggregate in my domain model.

Since it's not a CRUD thing from a database that I am retrieving/updating, do I continue to use a Repository or is there another pattern I should use in it's place? Or should I simply inject my adapter (IConversationAPIAdapter, not depicted in the diagram) into my Command Handler and let it create and return the aggregate back to the handler?

UML Design

2 Answers

If the 3rd party is creating the Conversation, then you don't really have an aggregate. You have at best a facade (the command handler) which just relays the command.

This is actually good, because it simplifies things. However, you should be aware that the returned object is not really an aggregate (as far as DDD is concerned), but a simple business (domain) object (in lack of another term).

You can still use the Repository as a pattern and send that object to be persisted if your app needs it.

Repository is a commonly pattern used in DDD.

The ConversationRepository (an interface) should be in your Domain Layer.

You can totally inject your implementation/adapter (from your Infrastructure Layer) into your ConversationRepository to retrieve your Conversation aggregates from the BDD and return it to your handler (your "Application Service").

Related