When developing software, architecture is crucial. Most of the time more attention is focused on developing and realizing requirements, instead of good, clean architecture. At Kien we always put software architecture first. Because this not only speeds up the development long term but it also brings stability, scalability, and extensibility. In this article we would like to give you a taste of the architecture of a medium to big project that we would use.
For a medium to big project we split the project up using an N-layered (or Onion-layered) approach. In short this means we separate all the core layers of the project. By doing this we can produce a system that at least has a layer for business rules and a layer for interfaces, with the main objective being separation of concerns. The amount of layers depends on the complexity of the project.
Looking at extensibility, this has many benefits for future applications. Most likely they will use the same database models, or need the same repository, but other concerns like the user interface (UI) will change. Imagine a project where we are asked to build a web application to monitor the status of machinery, or perhaps even control that machinery from within.
On one hand you have all the required logic to connect to the machines and on the other the presentation of the data to the end-user.
You could build all the code within this single project and everything would work fine. But then the client could eventually decide they want a mobile application as well (all the other requirements remain). If the single project/layer approach is used, there will be a lot of reimplementation of the same logic that was needed for the web application, because it was not separated from the web application and cannot be used directly. This will cost a lot of time and, of course, money.
If on the other hand the initial (web) application was built N-layered, all the needed components or layers could be referenced in the new mobile application project. This way you would have direct access to the previously mentioned layer and no redundant coding would appear. Separation of concerns.
Not only the reuse advantages, but implementing new requirements as well makes the N-layered approach a great way of developing. When a new business rule is introduced Kien can implement this in the appropriate layer and deploy only the new version of this certain layer, instead of having to redeploy the whole application. This brings in a lot of stability.
While we use the term “N-layered” a lot, this does not mean Kien uses this specific architecture all the time.
When we talk about scalability we often mean performance. By using the N-layered approach we can easily implement or introduce micro services (which relates heavily to service-oriented architecture (SOA)) to enhance the performance of the services, for example.
We at Kien hope we have been able to offer you a glimpse of the way software architecture design is implemented by Kien. Because of the size of the subject we will continue our talk about software architecture in an upcoming article, so we can dive into it a little deeper.