What is Software Architecture and why do we need it?
Before We dive deeply into Layered Architecture, I would like to be on the same page for Software Architecture.
So, what is exactly Software Architecture and why do we need it?
According to this article, Software architecture is the process of converting software characteristics such as flexibility, scalability, feasibility, reusability, and security into a structured solution that meets the technical and the business expectations.
This definition actually says it all. But you may feel that this is still vague. So, I would like to explain it in detail by using sample Golang code.
You can actually write all codes in one file
I would like to explain why software architecture is important by not using any architectures. Everything is written in one file below.
Here is the simple sample API.
It is just a simple transaction script. But there are some different roles out here.
- Connect DB.
- Get data from Http Request and convert it to programmable value.
- Access DB.
- Send back Http Response.
But hey!, what is the problem of this code?
I mean, there is nothing wrong with this code. It is working correctly. However it has potential problems like below.
- File gets bigger as the number of API increases and this can decrease the readability.
- It takes time to examine the causes of error.
- Different roles and responsibilities are all in the same place.
- Dependency of the code could be messed up.
- Therefore, it can collapse flexibility, scalability, feasibility, reusability (It can not meet the technical and the business expectations)
So… isn’t it just split codes into different files based on different role?!
Let’s just use software architecture then !
Two elements of software architecture
We have learned the definition of software architecture and why it is important. But what is software architecture made out of? What is the difference between code put into one file and code put into two files? one file code is not architecture then?
In my opinion, there are two elements to make thing to be called software architecture.
- Role and responsibility are split up.
- Dependency is one way. (not two-way)
I think that it can be called ‘software architecture’ when code follows these two rules. (Dependency is two-way sometimes, but let’s ignore it for now…)
View Controller pattern
There are many kinds of software architectures nowadays. we will look into it step by step.
First one that I picked up is called ‘view controller pattern’. This just has two layer(controller layer and view layer) . All the logics(http request validation, domain logic, db connection, db access and so on) are put into controller layer.
Here is the sample directory structure.
./
├── main.go
├── controller
│ └── post.go
└── view
└── post.htmlHere is the sample code.
Every architecture has pros and cons. And what are this architecture’s pros and cons?
pros:
・It is very simple and easy for beginners to capture the whole picture of the program.
cons:
・It decreases the readability of the code as product grows.
・It is almost impossible to encapsulate code in Golang.
How about next one?
MVC pattern
Let’s look into MVC pattern this time. This pattern has three layers called ‘Model’, ‘View’, ‘Controller’. I think this is the most common software architecture.
Here is the sample directory pattern.
./
├── main.go
├── model
│ └── post.go
├── controller
│ └── post.go
└── view
└── post.htmlHere is the dependency of each layer

View layer
View layer get data from controller layer and displays it to user in easy-to-understand format, based on the user’s actions. This layer may not be used if your sever just returns Json for example.(REST API server)
Controller layer
Controller layer takes data from Http Request and convert it to programmable value and pass it to View layer and Model layer. Controller is the interface between View and Model layer. It literally controls View and Model.
Model layer
Model layer structures data in a reliable form and prepares it based on controller’s instructions. Is has domain logic and technical implementation.
pros:
・Each responsibility is clear so that code can be split easily into each layer.
cons:
・Controller has to consider many things like(receive http data, converting data, handler view and model) so it can be fat controller.
・Model can be big and messy too because it has to deal with domain logic and db accessing in a same place.
Layered Architecture pattern
It is consists of four layers (Presentation(UI) layer, Application layer, Domain layer, Infrastructure layer)
Here is the sample directory pattern.
./
├── application
│ └── post.go
├── infrastructure
│ └── post.go
├── domain
│ └── post.go
└── presentation
├── controller
│ └── post.go
└── view
└── post.htmlHere is the dependency of each layer.

Presentation(UI) layer
The Presentation or UI layer would be views and controllers. This is the interface to the outside world. And this layer gets data from outside and converts it into programmable value. This can be a web page or a Restful API. All interactions with the systems should happen trough this layer.
Application layer
The application layer is the interface between domain and presentation. This layer is also responsible for coordinating domain objects and domain services to interact with internal or external services. The domain layer is not responsible for initiating communication with external services.
Domain layer
The Domain Layer is the core of your system. All your business models and services are defined here. This layers hold the rules and logic of the business. It’s the most important layer of your system. It is similar to model layer in MVC pattern. But this domain layer is not responsible for accessing DB or implementing technical things.
Infrastructure layer
The infrastructure layer is located at the lowest layer in layered architecture. It is responsible for accessing to database or outer service such as outer API, emails or messaging queues (sending the actual queue or email). Anything in this layer should be easy to replace.
pros:
The best thing about layered architecture is that you can separate domain logic from technical implementation. So you can avoid something like big model so to say.
cons:
It might be a little bit complicated for beginners to capture what is going on and code can be bigger. So, it is not suitable for small application.
Conclusion
I wouldn’t say that layered architecture is the best one and there are a lot more architectures in the world. But as you might have already noticed, software architecture is important to realize flexibility, scalability, feasibility, reusability to meet business expansion. So, Let’s select your own architecture based on your business, level of your team, where your product is going.
Reference:
confirmed my code works on following environment.
go version go1.12.5 darwin/amd64
