First, let’s define what software architecture is. According to Ralph Johnson, it is “the decisions you wish you could get right early in a project.” There are various formal definitions. However, I prefer this one from Ralph. You may often hear this term tossed around by software architects and developers when firing up a new project or revamping an existing one. Like forming a physical structure, software needs a blueprint to guide the engineers throughout the development of the application.
Speaking of architecture, one of the most frequently used ones is N-Tier (or three-tier architecture). If you’re a developer, there’s a considerable chance that you’ve already seen this sort of design.
To provide you with an analogy, this architecture could be accurately portrayed by a game called Jenga.
Now, if you’re not familiar with Jenga, it’s a game where your objective is to raise the structure as high as possible without it falling over. This kind of mirrors how the engineers are in a constant battle when developing applications.
You might be thinking, “What’s wrong with this architecture?”
The typical problem scenario is when a developer implements a new feature or modifies an existing one. There’s a tremendous chance of unintentionally affecting other components, especially if these layers have these inadequately written codes. Oh, and of course, if there are no unit tests.
That’s where the slice architecture can shine. It decouples the components by effectively making the features an independent slice of its own, unlike N-tier, where the services are classified based on their functions.
You can imagine it like a pizza.
Jimmy Boggard coined the term slice. He’s also the creator of Mediatr. If you’re accustomed to that library, chances are you’re also practicing the command query responsibility segregation (CQRS) pattern in .NET as well. Guess what? CQRS fits well on slice architecture too! This architecture is excellent for proof of concepts and small to mid-size projects without that much complexity.
If you are building an application from scratch, an architecture may already be in place. What’s a better complement, of course, is a blueprint for that structure.
That’s where the template comes in.
Templates are helpful if you ask me. You get the bare minimum to start. You don’t need to adjust or configure the bells and whistles on the project. You start writing codes right away.
Think of it as a recipe. Wouldn’t you want a formula that works already?
With the help of proof of concepts (POC) and small projects, prototyping quickly is advantageous because you can pull out the stuff that you don’t need. Just like when you’re using a recipe, you can tweak the ingredients depending on your taste.
But be wary – templates can be a dual-edged sword; some people like them, some don’t. I can’t blame them. People have their preferences. I understand, but tweaking or creating a project from scratch demands time and resources, and seldom do we have the luxury of possessing them. In these moments, I can recommend to start with the template and slowly chip away at the elements that you don’t need. Concentrate on starting so you won’t fall into a state of analysis paralysis.
Advantages for the developers
A question might be lingering in your mind: What’s the advantage for developers? Have you ever wondered why open-source projects are popular? One crucial aspect of it is that it’s open for everyone. People can gain information based on the knowledge of the people who have contributed to that project. Imagine: if you wish to implement something that you haven’t achieved before, the template can serve as a reference project. Do you want to create a containerised application? Want to see a functional test? How about a build pipeline YAML file? These can be extremely useful, especially to those who haven’t experience creating or implementing it before.
These benefits are not only for developers; many of them serve the organisation as well. A template tailored for creating a new project is a huge relief. You don’t need to prioritise figuring out the things that you need to include. Instead, you can immediately begin focusing on writing business logic instead of tinkering with what needs to go here and there. Also, you can churn out POCs faster. In my opinion, the odds of getting a new client increase when you can demonstrate that you’re capable of doing the things you said you could do in a fast manner.
As a gentle reminder, you always need to be mindful of how you architect your solution. The templates serve as guidance, not a silver bullet in every situation. The N-tier architecture is not necessarily bad as long as it’s not misused. Every architecture has its pros and cons. Knowing different types of architecture and templates gives us more flexibility when starting new projects and landing potential customers.
