Software Design Software Development Software Architecture .net core Event Sourcing Domain Driven Design
Developing a distributed system is hard. Understanding the domain is harder. Therefore it makes sense not to reinvent the wheel and use ready made solutions to help build your microservices right? or does it? Turns out the there is a lot to consider here. We will look at how to leverage the right tools to help you achieve a good outcome and a sustainable growth path. We will also explore strategies to not get locked in “frameworks” that only give you short term wins. We will see how our choices can have a long lasting impact and what to consider when making them.
Many developers make the mistake to locking themselves into frameworks that give them an easy win upfront. But as the software solution evolves you end up developing around the quirks of the framework rather than let the domain dictate the architecture. This eventually leads to un sustainable systems that make the domain harder to understand and reason with, making feature development painfully slow. I want to discuss ways to avoid this by picking "frameworks" that don't dictate how you solve business problems as oppose to being a tool or a layer which operates under the domain. Further I'll touch on the bad aspects of vendor lock-in and how to pick the tools that gives you the freedom to run on any cloud vendor.
Full stack .NET dev with distributed systems focus. Keen problem solver and improving cricketer. Currently working at Telstra Purple.