I remember the time, when I used to read the Design Patterns Book from the Gang Of Four. Those Design Patterns were pretty good for designing a solution for some of the design problems I faced. Also some really cool Object Oriented techniques to solve some common problem in software design.
For example, I remember using the Command Pattern to encapsulate behaviour and specific payload per command and pass it to different subsystems in a standard way. It worked really well and more importantly created a shared understanding of patterns amongst the team. Design discussions were an integral part of the project and it used to come up during Stand ups, Pairing, in Retro's and sometimes discussions over drinks too.
But, I'm talking about the pre Microservices - Monolith days where the LoC (Lines of Code) would easily go over a hundred thousand lines with the Monolith doing everything under the sun. You needed to have a lot of discipline, foresight and design skills to add code to such codebases, because bad design decisions could actually end up in a lot of refactoring down the line. Designing for the future is hard, but with a monolith you had to be pay a lot of attention to design.
I'm not saying Refactoring is bad, it is hard to refactor a Monolith where an interface has been implemented by a 100 different classes, changing the interface is a real problem. The author of the interface might have created it with a specific goal in mind, but the scope of the project would have gone far beyond what he/she had envisioned and it would have leaked into other classes. The more features you add the more complex the system is, because we tend to fit it into the design bets we made long time ago. In summary, Design patterns played an important role in designing monoliths with huge codebases spanning multiple teams.
Fast forward to the DDD (Domain Driven Design) and Microservices world, the scope of the Microservice is quite well defined and is limited in scope to what it will do. For example, an Authentication and Authorization service is concerned only about that functionality, an Inventory Service cares only about the Inventory domain. The scope of these Microservice's are limited and have separate codebases, which span only a few hundred/thousand lines of code and worked on independently by a few developers.
So, I question whether Software Design Patterns are relevant in a Microservices world?
Feel free to leave your thoughts in the comments section.
For example, I remember using the Command Pattern to encapsulate behaviour and specific payload per command and pass it to different subsystems in a standard way. It worked really well and more importantly created a shared understanding of patterns amongst the team. Design discussions were an integral part of the project and it used to come up during Stand ups, Pairing, in Retro's and sometimes discussions over drinks too.
But, I'm talking about the pre Microservices - Monolith days where the LoC (Lines of Code) would easily go over a hundred thousand lines with the Monolith doing everything under the sun. You needed to have a lot of discipline, foresight and design skills to add code to such codebases, because bad design decisions could actually end up in a lot of refactoring down the line. Designing for the future is hard, but with a monolith you had to be pay a lot of attention to design.
I'm not saying Refactoring is bad, it is hard to refactor a Monolith where an interface has been implemented by a 100 different classes, changing the interface is a real problem. The author of the interface might have created it with a specific goal in mind, but the scope of the project would have gone far beyond what he/she had envisioned and it would have leaked into other classes. The more features you add the more complex the system is, because we tend to fit it into the design bets we made long time ago. In summary, Design patterns played an important role in designing monoliths with huge codebases spanning multiple teams.
Fast forward to the DDD (Domain Driven Design) and Microservices world, the scope of the Microservice is quite well defined and is limited in scope to what it will do. For example, an Authentication and Authorization service is concerned only about that functionality, an Inventory Service cares only about the Inventory domain. The scope of these Microservice's are limited and have separate codebases, which span only a few hundred/thousand lines of code and worked on independently by a few developers.
So, I question whether Software Design Patterns are relevant in a Microservices world?
Feel free to leave your thoughts in the comments section.
