How I Design My Code
Programming is becoming mainstream nowadays. I saw people code and build some applications. As a programmer, I feel it wonderful that people start to learn programming.
Sadly, one thing that (almost) be sure, if something is becoming mainstream, its quality is getting worse. At least, that’s my opinion. Therefore, people start to make some ‘standards’ or principles so the code quality is (hopefully) good. I think S.O.L.I.D principles, Clean Architecture principles, and Design Patterns were made because of that fact.
I decided to unlearn then relearn those three principles in the last few months. I also tried to apply those principles in my projects. I may not grasp the full concept and implementation of those three, but I try to share what I learned.
The first thing to do to build an application is defining the requirements and business process(es). This is what I (try-to-always) do before starting my project. Let’s get down to code to see a real example.
Suppose that I want to make an application that can create an article and save it to a storage, it can be persistent or not. The application should also broadcast the article once it has been created. To make it a bit complex, the user should be able to read an article. That’s the requirements.
Knowing the requirements, I make this business process (written in Go).
That’s it! Yeah, that is the only business process I get so far. Now, let’s design the architecture.
As you can see, I defer the implementation details. Why? Because implementation details are not the most important decision when designing an application. Did you ever see an architect that care about what kind of brick or cement he/she will use before drawing the building prototype?
The more you read that code, the more you realize that it is a pure business process. The implementation details can be deferred until further requirements are collected.
After the requirements are (almost) fully collected, I begin to code the implementation details. I always put the implementation details in some different packages. I put database-related implementation details in database package, event bus-related in messenger package, and so on.
That kind of little architectural design is now my starting point to build my project. So far, this is the best starting point I know. Using the main business processes as an interface, I can add responsibility to it without breaking down the business process. Suppose I want to add monitoring responsibility, all I need is a struct that implements Blog interface. It is called Decorator Pattern.
I try to learn, unlearn, and relearn any known or new concept. Having said that, in the future, it may not be my starting point. So, until I find a better concept — or understand the current concept deeper — , I’ll stick to this concept.
