Posts

Bounded contexts or consistency contexts?

"Embrace modularity but beware of granularity"  ( Mark Richards)   While using the Microservice architecture in software can buy you some agility if done right, I often see architectures where microservices bring extra complexity that actually increases the implementation time. The microservice architecture often brings incidental complexity, that is often caused by the uninspired choice of our microservice boundaries. Bounded context should guide the choice of microservice boundaries. However, I find bounded context to be a too ambiguous concept. Any unit of software can be seen as a bounded context, even a class. A Payment sounds like a bounded context. What about a CreditCard , can it have its own bounded context? We don't want to create a microservice for each class, for sure. Think about this when you think to create another microservice, are you going too close to the "microservice per class" anti-pattern? On the other end, most real life software syste...

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...

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...