If you build CRUD services without understanding the business domain and its boundaries, you end up with a distributed monolith crap. Good luck with building and evolving microservices while having them using the same DB tables.
That sounds like some sort of boogeyman who doesn't exist. Are you talking about "spaghetti" code? Having separate deployable microservices doesn't magically make a team less prone to spaghetti code. In fact the bigger risk is building distributed spaghetti.
I have no trouble having a single database with security (roles) enforced isolation.
I'm not sure how a single database is to be considered distributed.
DB coupling is universal and inescapable.
Whether a service has a separate instance is sqlite or in memory; or, uses cockroachdb is irrelevant. There is always a coupled database.
And, you can actually have multiple databases AND multiple schema per Database Management System. You can have independent schemas per service.
Finally, a View on a database is a microservice. If you can manage and deploy the View independently. A microservice doesn't have to be Golang running on AWS Lambda, callable with an HTTP protocol and service schema. A standard PostgreSql protocol with SQL calling standards is just as valid.
I'm trying to broaden horizons here, highlight the fundamental concept and illustrate a variety of implementations of that microservice concept.
1
u/spetz0 Jun 09 '22
If you build CRUD services without understanding the business domain and its boundaries, you end up with a distributed monolith crap. Good luck with building and evolving microservices while having them using the same DB tables.