In the past few months, being stuck in the middle of a war, I had lots of time to myself. When the whole economy and job market collapses, you keep asking yourself what you’re doing. Since there wasn’t much to do, I chose to do what I love. Learning new things.
I like the excitement that comes with learning new things. Where to use it? Should I use it? Why do people use it? What problem does it solve? You know the drill.
I chose to take this valuable time and get arms deep in Event Sourcing and also learn to work with Marten & Wolverine. As wonderful as the critter stack is, Let’s leave it to other posts.
Complex Design, New Problems#
When reading about architecture I always hit the point of questioning everything. While complex architecture sounds exciting and makes things interesting, we don’t do business because it’s interesting. It’s the complexity of the domain, how more or less complex we make the solution to the domain, the budget, ease of production and team work that actually decides the fate of a project.
But we still keep finding and creating more patterns, architectural decisions and create more complexity. Simply because technology allows us to do more and more. But the harsh reality that I believe many developers will eventually hit in their professional life is that “You won’t be using that most of the time.”. See the emphasis on “most”? well, you might, but you know that not everything you learn is to use it in your next project. Unless you’ve learned the new interesting stuff because of your project.
Honestly, having one single project with simple folder separation and plain entities will get the job done for starters. Not all the fancy event-driven, microservices, message bus, redis cache stuff. To be honest it might even get you going for years before you or your client even thinks about developing further simply for performance reasons.
Keep it simple, Keep coming back#
I believe that the nature of software is iterative. You can’t write the perfect code or design the best systems on the first try; and you shouldn’t even try to do so. The only thing you should do is to keep your own hand open for future modifications. These aren’t new words. Many principles have been written and many great software engineers and developers have already discussed this. Way before I had even written my first line of code. I stand on the shoulders of the giants to remind you once again.
So if we know that we won’t be needing most of the fancy stuff most of the time, why bother learning at all?
To answer that question, I need you to remember your early days of writing code. The first “Hello World!” you printed to the console. You wouldn’t believe the amount of stuff you’d learn and apply in your daily job right now if you told them.
It’s about your vision. Your depth of knowledge. How far into the future can you predict and what actions you can take to elegantly keep things simple yet open to modification. You need to understand microservices so you can avoid using it most of the time. It’s kind of religious.
Outsourced Complexity#
But times have changed since many of the major patterns we hear about today had first been talked about. Tools have evolved and infrastructure has become more available and fairly affordable. While I believe that it’s important to keep the domain and your business as simple as possible, I also believe in not re-inventing the wheel. You don’t need to handle everything nowadays.
This goes to something I’d like to call outsourced microservices. Instead of me, the developer, breaking my domain into multiple services (Like OrderService, InventoryService, etc), I’ll keep it in one project. But that doesn’t mean I can’t use other domain-agnostic services that help me develop faster. I’ll be using Keycloak to handle users, ElasticSearch for a better search service, maybe RabbitMQ or Kafka (even though both the publishers and subscribers would be in the same service), etc.
It’s not new really. It’s about how available infrastructure has become. But there’s also something else. It’s about how easily you can use these services today. There are libraries that remove the friction working with each of these services had before.
As a modern software developer, you mainly need to be working on the business and the domain. They help you stay there more, instead of getting your hands dirty with lower level concerns. You just deliver the business, the RabbitMQ library you use will give you Outbox and Inbox for free and with a 1-liner.
This friction removing evolution causes good things, the balance between complex design and simple domain delivery can be reached easier. You can now write simple code, while having multiple services to lower the load on your service. Hence why I call it outsourced microservices.
I believe we should appreciate this. Being able to focus solely on our business code most of the time is a luxury not many had before. Simplicity is a choice born from knowledge, complexity is a gift of technological advance; combine both and you’ll have a stable system that’s easy to work with and easy to scale.
