|
|
|
|
|
by tentacleuno
1610 days ago
|
|
> Because we couldn’t isolate any of our services properly, this was going to mean that we would be left with a significant amount of duplication. For example, we identified one particularly complicated and essential piece of business logic that would have to be copy-pasted and maintained across 4 of the planned microservices. Wouldn't this piece of business logic be best placed in an import-able module? Then, that module would be imported by those 4 microservices and problem solved ...? I don't really understand this argument. |
|
Effective use of microservices depends upon a strong, meaningful boundary between the services and that boundary should be business driven, not code driven. As soon as you start dealing in packages of code[1], there’s no longer a meaningful boundary between your services, instead the boundary is completely arbitrary and each service becomes a microservice in name only.
If every microservice knows about the business logic for generating basket prices, whether the code comes from a package or not, you no longer have microservices… you have a lot of monoliths.
I joined a company that did this and it was one of my worst experiences as a software engineer, I would never recommend it.
[1] specifically packages containing business logic. Packages containing functionality for cross-service communication etc. are very reasonable.