How to model two bounded contexts with tight coupling between them

Question

Context

Hello, at my company we have been working with DDD for some time now. We have a monolith and some services. The bounded contexts in the monolith use HTTP calls to communicate between them or data replication/projections when it's needed. Now we have a case where we think we have two bounded contexts, but there are a significant amount of dependencies.

This part of the domain is based on CRM integration. We have an API to store Objects and Records (same behaviour as a CRM, but our implementation):

• The aggregate Object is an arbitrary object in a CRM (with configurable fields, etc)
• The aggregate Record is an instance of an Object.

It may seem I'm talking about OOP, but I'm not. This is the ubiquitous language in our CRM (and in others too, like Salesforce). For instance, Account would be an Object, and a specific account, would be a Record of the Object Account. Now, both Object and Record aggregates, are part of the RecordsBC bounded context. The RecordsBC contains the business logic of our own CRM-like implementation.

Due to the fact, that we are also an integration company, we also have a bounded context named CRMIntegrationBC, where our customers can choose to replicate their CRM data inside our application, keeping them synced. This is not mandatory, so one of our clients can be connected or not to a CRM.

As described, our business processes between these two bounded contexts are more or less like this:

So, for CRUD-related operations in the RecordsBC, if the company is integrated, we also need to replicate the data there, using the CRMIntegrationBC. We do this synchronously because we think introducing events for this is going to increase the complexity too much (we are not event-driven yet).

Question

So, I have some questions about how to model this:

Q1: Should RecordsBC and CRMIntegrationBC be separate bounded contexts?

From the beginning, I assumed they should be, because it seems the logic is quite different:

• RecordsBC handles our own CRM business rules and features.
• CRMIntegrationsBC handles CRM-integration things like how many users you can integrate, what objects, etc.

Nonetheless, given the high coupling between their use cases, I'm unsure about this fact.

Q2: If they indeed should be separate BC, how should communication take place?

Both of these modules live in our monolith, and we want to avoid direct import statements. For that reason, we thought that we would use a REST API to communicate with both contexts:

• To create a Record, our web/mobile clients would call POST /api/records, which would trigger the application service of creating a record in RecordsBC, which would handle the communication with CRMIntegrationsBC. Something like:

class CreateRecordService:
    def run(self, user_id, record):
        self._do_some_validation()
        # HTTP call to the API of CRMIntegrationBC
        if self._user_is_crm_integrated(user_id):
             # HTTP call to the API of CRMIntegrationBC
             self._create_record_in_crm(user_id, record)
        self._create_record(user_id, record)

Notes

Our tech stack consists of a Django monolith and some other different services (mainly fast API, and some NodeJS servers). Our BCs are set as follows:

src/
   shared_kernel/ # things like aggregate IDs and such
   RecordsBC/
       application/
       domain/
       infrastructure/
   CRMIntegrationsBC/
       application/
       domain/
       infrastructure/

Answer 1

Q1: Should RecordsBC and CRMIntegrationBC be separate bounded contexts?

I am not convinced that they represent different bounded contexts, but it it makes the architecture of your system easier, they can certainly be different modules that each listen to their own (internal) API.

Q2: If they indeed should be separate BC, how should communication take place?

Assuming you use HTTP communication between the two modules (or contexts if you decide so), the check if a user is connected to an external CRM should be done within the CRMIntegrationBC module. That keeps the logic nicely contained.

If you support multiple CRMs to integrate to, you could even arrange that a POST /CRMIntegrationBC/<user_id>/create is responded to with a 3xx redirection response giving the actual CRM type that the user is connected to. For a non-connected user, that external CRM type would be a dummy implementation that simply discards all incoming data and replies with 404 on all data requests.