Fork me on GitHub
#architecture
<
2022-07-21
didibus00:07:36

I think Polylith or something like it sounds best. Basically you want different teams to not all work on the same code base, so they can be faster and not step in each other all the time, but you have a shared application between them (since its a monolith), which means they all share infra, like same git repo, same compute instances, same database, etc.

didibus00:07:02

Polylith creates a similar kind of strong code boundary as microservices, while enabling it all to be built together into one app running on the same compute and data resources.

didibus00:07:32

Now, I would say, be careful about your hidden data dependencies. You might still have a challenge where each team ends up sharing the same database and database schema/serialized representation, it's like shared global state at the organization level.

didibus00:07:45

Normally microservices each have their own storage layer as well, which is kind of like immutable copies. Each team gets its own copy of the data and ownership over their own data schema and storage.

didibus00:07:17

So if one teams needs to add, remove, break apart or alter the shape of the data they use, it doesn't affect other teams.

didibus00:07:38

The downside is that joining the data or reconciliation of the data across teams can be difficult now that different parts of it are stored in different places. So there's trade-offs, but in terms of enabling teams to be more independent and deliver faster, I find having independent data schemas and storage a big benefit. I think you could also do that with Polylith, make sure the modules don't share a data layer/schema/storage. Have a database per module if you need too. Don't let one module get data produced by another module through a shared database, have them fetch it from the module interface of the module that owns that data.

didibus00:07:13

And what can help is having a module be an authority on data grouping. For example, you can have an authority on customers that return their global ID, and all modules that store associated customer data should offer a way to other modules to retrieve their relevant data through that shared customer ID.

didibus00:07:08

Instead of each modules re-inventing the concept of a customer with their own identifier for it, because then it becomes really hard to say get all the customer data across all modules.