Posts

Dependency Inversion for Entities - software architecture

Image
  Problem to solve: We create a core software entity, for example a  Product  - this will become  root  or  parent  entity Then we create multiple "child" entities that depend on  Product . For example  Order  and  Warranty . We have business rules for the "parent" entity that depend on "child" entities. For example you cannot remove a  Product  if there are in-flight  Orders;  or if the  Warranty  period is not over for all the instances of that  Product We want to avoid putting all those business rules in  Product , because such "tight coupling" would make the software harder to maintain as the system grows. Solution: TLDR: It helps to imagine the entities  Product ,  Order  and  Warranty  as defined in separate software modules, either in a modular monolith or in a microservice architecture. This will highlight the loose coupling we want to achieve. Howeve...
Post a Comment
Read more

Microservices: Software decomposition is not for performance, it is for the human brain

You can actually prove that most software systems would work faster in a monolith than in a microservice architecture. Just put back together all the microservices in a monolith, mentally. Replace all the REST calls with direct Java calls, this should eliminate a lot of extra work to serialize/deserialize.  The resulting system will consume less resources overall just by less serialization. The latency should be smaller without the network calls. If you eliminate all the workarounds added just to make the distributed transactions to work, the performance should be significantly higher - with a proper load balancing of course. There are some edge cases, like if your resulting application does not fit into DRAM, however this is rarely the case. The horizontal scalability should still work is you deploy enough of those monoliths and correctly balance the work among them. Of course, the starting time might be higher with the monolith. The risk for Out Of Memory from one module to the o...
Post a Comment
Read more