I have been using the clean architecture by Uncle Bob (Robert C. Martin) for over an year. It is something we use everyday for our development of micro services.

What is clean architecture?

Clean architecture is software development concept and practice for separating the business domain with application logic. The idea behind this is that the business logic rarely changes while the application logic and the other external entities of the application might change over the time.
There are three different sections in clean architecture. Those are the business logic, application logic and external entities (such as 3rd party APIs, databases and other libraries).
If there is a change requirement for application or external entities, clean architecture will help to keep the existing business logic intact while you can make any changes to the other sections. Clean architecture also helps to write strong unit tests to business logic expecting it to pass every time other section is changing (given that business logic does not change over time)
Clean architecture uses other practices such as dependency inversion from SOLID.

How we do it

On our organization we use our own approach for the practice. We load the external entities as class instances and inject them into the business logic at the constructor. The business logic can work on their own as long as dependencies fulfill their duty as constructor parameters.
Usually the business logic works on its own even with the drastic changes like database change or changing the application framework entirely(like changing entire database from MySQL to MongoDB).
I'm not going to jump onto code level stuff, so I will stop it here.

Pros

I am not here to show you how to do clean architecture and stuff, but to give my experience about it. There are couple of practical pros we experienced the throughout our development phases. Some of them are:

1. Maintainable solid clean code base
We know the structure of the code base, where does the database connections, API calls, repositories, adapters, controllers and models resides. We know how each of the above terms connects and communicates with each other. We know if something is in the wrong place. In other words we know which goes where, when and which. All thanks to clean architecture enforcement. This ease up the effort of code reviews and quality standards.

2. We have lot of reusable components
Since clean architecture separates external entities, we have lot of components such as adapters at our disposal that we don't have to write again.

Cons

Unfortunately I see lot of Cons instead of Pros in this manner. Let me note down the disadvantages of clean architecture

1. Lot of boilerplate code
   Unfortunately to get up and running a clean architecture you need to write lot of boiler plate code. When comparing to picking up a MVC vs using clean architecture on top of a framework, clean architecture requires lot of pre programming before actually implementing something.
2. There are no IDE voodoo magic
   I could not find any plugin to VS code or JetBrains IDEs that support clean architecture apart from directory structure generation. The support we get for well-known frameworks and libraries are awesome. But there are no such support for clean architecture.
3. Clean architecture works best with some specific use cases
   Well, certainly it is not the swiss army knife of programming paradigm. There are lot of scenarios where we can safely build without using clean architecture. The whole idea of "business logic rarely changes" is not applicable to all the problems.
4. Technology evolves so fast that maintainable code base is not actually worth it
   This is very personal opinion of mine, so take it with grain of salt. But there are lot of discussions built around this (Ex: Apple phones and Nokia phones, 2001 vs 2021). I personally believe any system that we build today will be a legacy system after the next 5 years. So we need to reengineer it to keep it up to date with the latest technology. With that, rapidly developed working software is more important than maintainable, debt-free code base.

Conclusion

Will I use clean architecture in the future? Yes, but not for everything. It actually depends on the requirement and its factors like scalability and size of the scope.

But I would not use if for all the applications that I would build in the future.

A blog is a collection of articles that appear on a website. These articles can be anything. Majority of the blogs pick a subject and most of its articles stick to that subject. Most take the form of a diary or a journal which records the date it was published and walk through writers’ experiences.

Blog vs. CMS

CMS stands for content management system. Those are built for people who do not want to develop a website on their own. They can simply grab a CMS, install it and update its content while changing the look and feel with a graphical user interface. A blog can reside inside the content managed website, as the CMSs can facilitate the blog as well.

But some people want a blog only. Since CMSs provides an easy to use interface and a lot of community support, people stick to CMSs even if they want just a blog.

CMSs

The most common CM systems today are WordPress, Joomla and Drupal. All of these are written in PHP. They are well known for having huge community support which includes plenty of themes and plugins to turn a CMS into an ecommerce website or a booking engine.

There are free hosted solutions too. Such as Blogger, Tumblr and WordPress.

Selecting a CMS framework for blog site development is a bit complicated as most of them have different approaches even though all of them do the same thing. I was a wordpress developer some time ago. It was a very tedious process to develop a wordpress website because wordpress deviated from most of the software development practices today. For example wordpress does not adapt common database modelling patterns. It has its own database structure and it is not easy to use as a traditional relational database approach. And most importantly it does not have taken the object oriented approach seriously.

Drupal on the other hand has the most complex workflow. You have to create placeholders and views to accommodate custom theme code.

Ghost

Ghost is a CMS written in Node.JS. Currently it's in third version. Ghost is identified as headless CMS, which means that you can have your own application for the front end while Ghost handles the data.

Why Ghost?

Ghost is the most popular Node.JS CMS solution and I love Node.JS. It has a cleaner codebase than other CMS software. It’s fast, reliable and very flexible. That's why I picked it.

Feel free to comment what you think below.

Creating your own portfolio is beneficial in many ways. With a good portfolio you can show off your skills while showcasing your creativity.

I created my portfolio in three days (around twenty hours). I will guide through the process of creating the website. You can see the website here.

TLDR; Source: Github

First thing I did was listing down sections and pages I was hoping to put. I went with the home page, about me page and contact me page. (I added a blog, but that comes later). My home page has the following sections except header and footer.

• Hero section
• Introduction
• Experiences
• Skills
• Projects
• Contact information
  

The About me page contains simple text. Contact me page has two sections. Description and contact form. For this template I left form action blank as you can decide how to manage the form action.

Then I sketched how those sections were going to line up on the page. I like to have a constant color scheme. So I selected four colors. Which are the main colors of Dota 2. I just went with two font families as I like to keep a minimal look and feel.

Colors:

Fonts:

• Allerta
• Inconsolata
  

Finally I decided the tech stack I am going to use. You can see the details below.

Main stack:

• React.js with react routes, axios and moment.
• Bootstrap as react-bootstrap.
• FontAwesome for icons.
• Animate on scroll for animations.
• SCSS for css.

I didn’t use any state management library or framework as the functionalities of this website are not that much complicated.

You can get the files from above github. I will guide what each file does and the purpose of each directory.

File structure:

│   .gitignore
│   package.json
│   README.md
│   yarn.lock
│
├───public
│   │   favicon.ico
│   │   index.html
│   │   logo192.png
│   │   logo512.png
│   │   manifest.json
│   │   robots.txt
│   │
│   └───assets
│       └───images
│               logo-small.png
│               logo.png
│               profile-reduced.jpg
│
└───src
    │   App.js
    │   App.test.js
    │   index.js
    │   serviceWorker.js
    │   setupTests.js
    │
    ├───assets
    │   └───css
    │    	   style.css
    │    	   style.css.map
    │    	   style.scss
    │
    ├───Data
    │       Companies.js
    │       Projects.js
    │       Skills.js
    │
    └───View
        ├───Page
        │       About.js
        │       Contact.js
        │       Home.js
        │
        └───Partials
            │   ContactMe.js
            │   Footer.js
            │   Header.js
            │
            ├───Project
            │       SingleProject.js
            │
            ├───SkillBar
            │       SkillBarItem.js
            │
            └───Timeline
                    TimelineBadge.js
                    TimelineItem.js
                    TimelineRow.js

This is a react app created with create-react-app. I used yarn as my package manager.

The public directory holds the default react files and the images I used for the website.

The src directory holds all the default source I wrote. First of all I added the style.scss to the assets directory inside src, and imported the generated css file in App.js

Data directory contains the data objects of the website. It does not require a back end system as the website is not going to hold a lot of information and it won't be updated frequently.

Inside the view directory there are some sub directories. Page takes care of the skeleton of the home, about and contact pages.

Partials are commonly used components such as header, footer and contact section. The sub directories inside the Partials are related to templates in the home page.

The Project has a single project item which is iterated and called on the home page.

SkillBar and Timeline components function like the single project as well.

So that's it. If you think this is a good portfolio, check the github repository.

I am Janaka Dombawela. A full stack developer based in Sri Lanka.

I just started a blog as part of my portfolio website so I can share my knowledge and thoughts with the world.