Manage multiple projects in the same DDD subcontext

Question

I'm here for some advice about how to manage the situation where I have a legacy application running locally on an onpremise server with it's own database and I'm about to add an online shop app to it. I have created a new domain model for the context and added an anti corruption layer (ACL) to convert the data. This ACL will reside in a windows service that communicates via queues with the main online shop app to keep the data in sync and register the successful transactions into the legacy db.

so the whole can be schematized like that:

LegacyApp <- ACL <- WinService <-queue-> CloudApp

1. Could it be right to consider the windows service and the cloud app as parts of the same bounded context, or should each be represented by it's own bounded context ?
2. If so, having the domain model shared, the communication over the queue should in your opinion be based on DTO's or directly serializing the aggregates?

Thanks

• Rik D: I hate ambiguous abbreviations. ACL in the Domain Driven Design context means Anti-Corruption Layer.
• Kiske1: My fault... I should have specified better. Yes I mean an anti corruption layer

Answer 1

When the Windows service is developed together with the online shop app by the same team, maybe with a similar programming ecosystem, it is probably more sensible to see them as one application system and model them as parts of the same bounded context.

The situation would be different if there are two independend teams, which see those two components as decoupled applications. Maybe the Windows service is so complex it requires another team for this job. Maybe the online shop app is a 3rd part component which was already created by someone else and now is just tailored fot this specific scenario. That would be a reason to use two bounded contexts.

The answer to your second question is quite similar: when you know for sure both parts are developed by one team using the same programming ecosystem, with a similar serialization mechanism available at both ends, serializing and deserializing directly makes sense and can save you some effort. Otherwise, using a more technology agonostic mechanism like DTOs would probably make sense.

• Kiske1: Thanks, exactly what I thought. As both projects are developed by the same team I think we'll go with the single boundend context, directly serializing the domain entities.