The goal of our third generation codebots (C#Bot and SpringBot) is to use a microservices architecture. But within each microservice, it is important to have an architecture that is consistent and seperates the concerns of the application. In this article, we introduce the architectural style used by the third generation bots and talk about some common handling techniques you will likely want to know about.
As students of software, we are all taught a few principles that carry with us for our careers. For example, don’t repeat yourself (DRY). This is something we are learn early. If you copy and paste a section of code then you should likely put that code into a function and call that function as required. Another of my favourites is the seperation of concerns and this one can be applied at an architectural level as well.
The goal of our third generation codebots (C#Bot and SpringBot) is to use a microservices architecture. Microservices are what all the cool kids are aiming for these days and microservices very much uses the concept of seperation of concerns.
However, even within each microservice an architecture is important. We have found that having a codebot write the vast majority of the code base creates a highly consistent architecture and can reduce the technical debt of an application when there is a clash of architectural styles.
In the rest of this article, we will look at an architecture that is an oldie but a goodie and also examine some important things I always like to know about an architecture when I am first learning about it. Namely how logging, exceptions, and security is handled.
Handling the important things
As an old school techie, these are the 3 things that I want to learn about when I am looking at an architecture. I have found that when these are done well on top of a consistent architecture, programming becomes a lot more enjoyable.
Writing to log files is important for a number of reasons including debugging. So, each of the codebots writes to log files and when adding in custom code into protected regions, you may want to add in some extra logging too.
Throwing and catching exceptions when done well, really adds to the maintainability of an application. Knowledge of how the architecture uses exceptions is super important.
Finally, how is security handled. Authentication, Authorisation, and Auditing (AAA) are all very important parts of an application. If you create a new API endpoint or any custom code for that matter, you better make sure it is secure!
N-tier is still relevant
There is nothing like a healthy debate about architecture. The thing about it is that you will get different opinions depending on who you talk to. In my opinion, the most important things about architecture is consistency and the separation of concerns. If this is done well (and everyone buys into it and rows in the same direction), then good momentum can be gained by the team. It is best to pick an approach and stick to it. Technical debt can rise very quickly when competing ideas clash.
An N-tier architecture uses a number of tiers that have different responsibilities. The following diagrams shows a possible layout and is a good general purpose approach. The names of the layers are pretty self explanatory and each of the third generation bots uses a variation of this. You will come across their N-tier implementations in other articles specific to them.