I am quite new to DDD, but I am currently working on a system which has a payroll element to it. I have a requirement to send payslips to an external system when they are created. Currently the payslip process is all in the existing legacy code, but I was thinking that it might be a good chance to move some code into a bounded context that has recently been created for payroll to slowly migrate the legacy code to. The system isn't distributed so everything all runs in one process.

My thoughts were to make an application service which would orchestrate calling an infrastructure service to send the data to the external system and then update the status of the payslip. This would be called from the legacy code. Is an infrastructure service the right thing for this integration, or is the whole thing a design smell?

closed as too broad by Robert Harvey Jun 3 at 17:58

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • even if it's a monolith now, are you interested in making the system "distributed-ready" or is it never going to happen? – guillaume31 Jan 4 at 12:13

This is more of an architecture question than DDD. DDD can be implemented with 2 tier, 3 tier, Clean, Hexagonal, etc. It appears from the terms you used in the question that you are using something similar to Clean Architecture, so I’ll make that assumption.

An infrastructure service is where you would implement the service to make the eventual call to the external message broker, but getting the message to be sent from the domain model and into that infrastructure service seems to be where you’re stuck.

In the domain model, declare an interface for a messaging service that is generic (i.e. does not use anything declared by the messaging service you end up using). Implement the service that calls the external message broker in the infrastructure layer, and make it implement the interface in the domain layer. Now you can either inject that service into your domain objects, or pass it in from the outside if it’s not used often. This sidesteps the need for the application service which would do nothing but pass the message on.

BTW, even if all the code is running in the same address space, you should use a message broker. This creates a seam to allow breaking off that domain in the future into a microservice of its own when your app becomes unexpectedly successful.

Not the answer you're looking for? Browse other questions tagged or ask your own question.