Best Practice for Integrating Domain Services with Infrastructure Layer in Clean Architecture

Question

I'm currently implementing clean architecture in my project.

My application includes various types of communication protocols (TCP, HTTPS, etc.) implemented in the infrastructure layer.

These communication protocols are responsible for handling incoming and outgoing network communications.

I need to process the incoming data and prepare outgoing data, which involves significant domain logic.

Problem:

I am unsure whether to inject domain services directly into the infrastructure layer for processing this data or to use a different approach that adheres to Clean Architecture and DDD principles.

Specifically, my questions are:

• Is it architecturally sound to inject domain services directly into the infrastructure layer for processing data?
• If direct injection is not advisable, what is the best practice for allowing the infrastructure layer (communication protocols) to interact with domain logic without violating the principles of Clean Architecture and DDD?
• Would using domain events or interface-based communication be a better approach in this scenario? How would this be structured effectively?

Additional Details:

My domain services contain the core logic for data processing.

The communication protocols in the infrastructure layer are the primary components that interact with the external world.

I would appreciate guidance on the best architectural approach for this scenario, along with any examples or patterns that might be relevant.

Answer 1

I am unsure whether to inject domain services directly into the infrastructure layer for processing this data

Why would you…

Ooh. I see. You’re trying to parse out business stuff to build your request model. Don’t do that.

It’s ok for the request model to hold unparsed stuff. That stuff can be parsed later by the business aware Interactors as they build entities.

Now that’s just one way to do it. But in no case should you be letting business logic leak into the outer layers. Forget clean architecture. The OSI stack shows us how to separate transportation concerns from application concerns. Don’t shove your business rules down into TCP aware code. Resolve the TCP issues and dump the rest of the data on the next layer to deal with it.

osi - allroundcomputersolutions.weebly.com

The important thing to understand here is, despite the fact that you can understand every part at every layer, the layers can’t. All they care about is that green part. The rest is a payload for some other layer to deal with.

Adopt that mentality and you can separate your business aware code from your protocol aware code.

Now, with that in mind, the arrows in these diagrams show what knows about what. To know about something you either build it or get handed a reference to it.

Sure, that last one is an injection. But just because you know about something doesn’t mean it returns anything to you when you call it. Some things you call and just trust that it’ll deal with what you told it to do.

This can lead to the flow of control going off on a life of its own.

Which means you don't have to worry so much about flow of control when constructing the clean architecture onion. _{This is thanks to DiP}

What you should worry about is that things must exist before you can shove them into other things:

My DI pattern for constructing immutable persistent objects in CA

If that’s what you mean by “inject domain services directly into the infrastructure layer” then sure. To call something you need a reference to it. But that isn’t moving the business logic. That’s asking the business logic to do its thing.

Uncle Bob doesn’t talk that much about construction or DI in his books. His diagram is about what he wants once construction is done. If you want to read more about Dependency Injection I recommend Mark Seemann

Answer 2

I think more detail to your question would be useful. But let me try a naive approach to answering your direct questions assuming you have some standard business process application.

• Is it architecturally sound to inject domain services directly into the infrastructure layer for processing data?

No. If anything it should be the other way around, or (see my other answer to this similar question : Should domain services in a domain-driven design invoke the data warehouse interface？) not at all.

the core logic of your domain shouldn't care about what happens before and after processing the data. You should try and make it work purely in memory on your domain objects.

• If direct injection is not advisable, what is the best practice for allowing the infrastructure layer (communication protocols) to interact with domain logic without violating the principles of Clean Architecture and DDD?

The infrastructure layer should not contain or call your domain logic.

The infrastructure layer should contain stuff that deals with sending your data over the wire, saving it to disks, calling external services etc

• Would using domain events or interface-based communication be a better approach in this scenario? How would this be structured effectively?

For you scenario of "get incoming data, process it, send it out again" you should structure you application as follows

public main()
{
   while(1==1)
   {
     var dataIn = Infrastructure.IncomingClient.Get();
     var processedData = Domain.Dataprocessor.Process(dataIn);
     Infrastructure.OutgoingClient.Send(processedData)
   }
}

There is no obvious need to inject anything into anything else.

Now If you want to wrap this application up in some object, call it a "Use Case" and run it from an even simpler application, then sure have it reference interfaces for the various objects and inject them. Then your references all flow in the right direction.