Right now we have a monolith application, and we will still have one monolith probably for the following years. What we are trying to do though, is to break the responsibilities more clearly in well-defined bounded contexts. For this question, let's say we have two bounded contexts:
- Company bounded context: in this bounded context we handle companies and their users.
- Objects bounded context: this is like a CRM, where we handle a ton of different objects, that can be extended following certain rules, etc.
The main thing here is the Objects can be owned, modified, and created by users in a company. So we save that data in the Objects bounded context. Now, the User aggregate has too many things that we do not need to do: like we do not always need to. For instance:
- To store who created an Object, we just need the user id. Same with who updated it, who is the owner, etc.
- In some report operations, we do need the email of the user, because instead of showing the user id in the CSV report, we prefer to show the email.
Right now we are sharing the same class in both bounded contexts, using just a direct import. Nonetheless, this has one problem: when testing, we need to create User instances that have too much data that we do not care about, making our tests harder to write, read and maintain.
To fix this, we are thinking about decoupling, but we are not sure who. Our main idea is to just create a repository for users in the Objects bounded context and use a different representation. This repository would not update any data because read-only access to the Users is more than enough. Something like this:
companies/ domain/ users/ user.py # Full User object with all the data users_repository_interface.py application/ users/ users_repository.py # This handles full User objects ---------------------------------------------------------------------------------- objects/ domain/ users/ user.py # minimized version of the user users_repository_interface.py application/ users/ users_repository.py # Kind of an anti-corruption layer, calling the other # repository under the hood and convert the full user # to the reduced representation of this bounded context
We are not sure if this is the correct approach to decouple this. Maybe the class does not need to be a repository and be called something else, like a connector or something. Any ideas/recommendations on how to approach this?
Note: A justification for this approach is that right now the Objects SQL table has a Foreign Key to Users. We also would like to delete that and just use a normal field like varchar or int to represent the user id, without the foreign key thing. This will make our integration tests in the Objects bounded context way easier to write, read and maintain.