Software Architecture

When we design a building, we usually design it base on plane walls and right angles. Why is that? Sometimes we design a round form, however that becomes way more complex to build. Still, we try to stick with simple forms like circle arcs. The Sydney Opera House was architected with unusual round forms at the roof. That project "was completed ten years late and 1,357% over budget " ( source ). The project really gained speed when they reduced the complexity of sail-like round forms to reusable (smaller) building blocks. In software you have the same problem. If you don't find reusable building blocks - as reusable code or reusable patterns - the complexity of the project grows exponentially, and you find yourself over budget (time and cost).  In software, you rarely need something as sophisticated as Sydney Opera House. Therefore, try to reduce complexity as much as possible if you want to finish your project in realistic time. Simplicity is the ultimate sophistication ...

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