CODEWITHSUNDEEP
restdomain-driven-design
Milivoj Milani
Milivoj Milani

Reputation: 335

Fetching potentially needed data from repository - DDD

We have (roughly) following architecture:

  1. Application service does the infrastructure job - fetches data from repositories which are hidden behind interfaces.
  2. Object graph is created and passed to appropriate domain service.
  3. Domain service does it thing and raises appropriate events.
  4. Events are handled in different application services which perform some persistent operations (altering repositories, sending e-mails etc).

However. Domain service (3) has become so complex that it requires data from different external APIs only if particular conditions are satisfied. For example - if Product X is of type Car, we need to know price of that car model from some external CatalogService (example invented) hidden behind ICatalogService. This operation is potentially expensive one (REST call).

How do we go about this?

A. Do we pre-fetch all data in Application Service listed as (1) even we might not need it? Do we inject interface ICatalogService into given Domain Service and fetch data only when needed? The latter solution might create performance issues if, some other client of Domain Service, calls this Domain Service repeatedly without knowing there is a REST call hidden inside it.

Or did we simply get the domain model wrong?

This question is related to Domain Driven Design.

Upvotes: 0

Views: 505

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57299

How do we go about this?

There are two common patterns.

One is to pass the capability to make the query into the domain model, allowing the model to fetch the information itself when it is needed. What this will usually look like is defining an interface / a contract that will be consumed by the domain model, but implemented in the application/infrastructure layers.

The other is to extend the protocol between the domain model and the application, so that we can signal to the application layer what information is needed, and then the application code can decide how to provide it. You end up with something like a state machine for the processes, with the application code coordinating the exchange of information between the external api and the domain model.

If you use a bit of imagination, you've already got a state machine something like this; as your application code is already coordinating the movement of inputs to the repository and the domain model. The difference, of course, is that the existing "state machine" is simple and linear enough that it may not be obvious that there is a state machine present at all.

how exactly would you signal application layer?

Simple queries; which is to say, the application code pulls the information it needs out of the domain model and uses that information to compute the next action. When the action is completed, the application code pushes information to the domain model.

Upvotes: 1

Louis
Louis

Reputation: 1241

There isn't enough information to give you targeted good advice. I suspect you need to refactor your domains into further subdomains. It sounds like your domain service has way more than 1 responsibility. Keep the service simple.

In addition, If you have a long running task like a service call that takes a long time, then you need to architect it away. The most supple design will not keep the consumer waiting. It'll return immediately with some sort of result to the user even if it's simply a periodic status update.

Upvotes: 0

Related Questions