Modular Monolith with DDD and Legacy data

Question

In my domain i have the following modules:

WMS(Warehouse Management) SalesOrder(Contains salesorderline, etc..) This is a multi tenancy application, which means the database contains many companies, each company has it own set's of data. There is alot of crud, but also a big portion is operational.

Some data comes from a legacy-system, how would you go about making an integration here? There will be an integration running a time intervall and sending data to the API, writing both up and down(keeping in sync). So basically i'm asking how to import existing data into the system and should not this problem be a distributed transaction? There may also be data imports from other systems. The reason the data needs to be kept in sync is because the legacy have to live for a longer while.

Edit:

Let's say both modules stores it's own version of product:

WMS.Product:
- ProductName
- ProductNumber
- QuantityInStock

SalesOrder.Product:
- ProductName
- ProductNumber
- RetailPrice

Should the integration command look like:

Integration.Commands.SaveProduct
- ProductName
- ProductNumber
- RetailPrice
- QuantityInStock

And shouldn't this transaction be distributed across the different modules?  If the transaction goes both ways there will have to be some kind of link between ids..

How to implement an anti-corruption-layer from legacy system with god models, when the integration have to go both ways..

Thanks in advance.

Answer 1

Here's what I suggest:

how would you go about making an integration here?

You integrate like you would any other external part of the Domain (like the database for example). Create a "connector" whose only job is to interact with that system and translate from your Domain to that system and vice-versa. One "interface" that your Domain can reach out to that will mask the details the details of the interaction and is implemented on the infrastructure layer.

i'm asking how to import existing data into the system...There may also be data imports from other systems

If you have a similar set of steps for importing and exporting data from your system, you can create a single interface and create a connector that implements that interface for all the data imports.

In summary, treat this like an external system (because it is) and read/write to it through the infrastructure layer like you would a database.

Edit: Based on your edit

A Cleaner Approach

You need 2 different commands. One to update the Warehouse and another to update the sales order.

So, Instead of Integration.Commands.SaveProduct, you'll have Integration.Commands.PulledProduct and Integration.Commands.OrderProduct. When you sell the product, your domain could itself trigger a "Pull Product" event that gets handled by the WareHouseManager Module. Your external trigger must be able to distinguish between the commands. You'll see integration becomes almost "logical" if you take this approach.

A way to think it about it is with the Ubiquitous Language. An SME might describe your system as "The user puts in a sales order (event 1) and then we pull the requested quantity (event 2) from the warehouse". So, those 2 events must be distinguishable in your domain. Let me know if I am still not getting a clear picture.