## 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 behavior 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:

[![enter image description here][1]][1]

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 will use a REST API to communicate both contexts:

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

```python
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 NoseJS servers). Our BCs are set as:

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

  [1]: https://i.sstatic.net/MY1JvHpB.png