Extracting services and managing data consistency
Going back to the 01-monolith_legacy branch, you can observe the original database used in our ERP. Figure 8.6 shows the original database with both the SalesOrder and Availability collections:
Figure 8.6 – Common table ownership
As you can see, in the beginning, we had a situation where multiple services relied on a single database to store and access all the collections they needed—for instance, services such as SalesQueryService or AvailabilityQueryService in the ERP code base. In this scenario, any of these services can modify the data in each collection, which creates several risks. Because all services have direct access to the same collections, there is a high risk of tight coupling.
Just as all collections are in the same database, all the services are in the same code base. In our ERP, we have just one module that is responsible for updating all the collections, BrewUp.DomainModel. Figure 8.7...
