Designing Modern Applications: 5 Key Principles

We are going to discuss 5 key principles to use as guideposts to design modern applications.

Since the early days of software architecture and design, there has been a tendency to capture good practices. These practices have traditionally been called design patterns, first becoming famous as the gang of 4 design patterns. These design patterns have been timeless though there have been attempts to modify them or add to them as new frameworks have emerged. They were also written over 2 decades back and a lot more learning has been experienced by the tech industry since then. What I belive is that in the modern cloud-native era, it is more important for developers to understand normative principles behind all good software architecture than prescriptive design patterns. Look at these principles as virtues, it may not be possible to stick to them in every situation but the best attempt should be made to do so.

Now, let’s dive in.

Design Principle #1: Everything is a State Machine!

Like humans, every live software component has life-cycle stages and associated states. Rather than how a component is behaving internally, the focus should be on how states are changing. These states are conveyed in the form of events.

I remember during my developer years, I learned that the best way to put comments in the code is not to put comments at all (except API documentation which is different). The idea was that code should be written in such an easy-flowing way that when someone is reviewing the code, they do not need to take the help of comments. To make the code comment-free, meaningfulness needed to be inserted into each part of the code. The same applies to the states and events. If a software component is designed the right way, its states would so meaningfully be conveyed by the events that there would not be a need for a messaging framework Every other component interested in the life-cycle of this component should simply observe these events and that would be sufficient.

Design Principle #2: Convention over Configuration!

These days there is a lot of talk about configuration as code. There is something better than configuration and that is convention. Convention means that it is unnecessary, confusing, and counter-productive to configure best practices. Best practices should be hard-wired in the software or framework.

One good example of that is Roost.io environments as a service platform that has all cloud-native best practices hardwired in the platform Driving on the wrong side of the road should not be a matter of choice. In the same way, dangerous features like root or privileged containers should not even be allowed.

Design Principle #3: The Law of Immutability!

There are various ways to define the law of immutability and this principle is a close associate of principle 1 i.e state machine. The key idea is that when an object carries a certain state, there should be no way to corrupt this state. If the state needs to change, a new object with a new fingerprint needs to be created.

Design Principle #4: The Git Principle!

The Git Principle can also be defined as the network of trust principle. The key idea is that merit of a software artifact is best determined by how much the network trusts and validates it. In the early days of git, the best Linux commits would get promoted by more and more developers cloning it and the commit eventually making it to Linus Torvalds repository.

Design Principle #5: The Hollywood Principle!

When an aspiring actor goes for audition in hollywood and after the audition is over he/she is told “do not call us,we will call you”. This is the hollywood principle.

This principle is also called inversion of control and is mostly enabled by a feature called dependency injection. This principle can also be called the principle of loose coupling. The key idea is that dependencies are injected at run-time in a software component so that this component is not hardwired for a specific type of dependency. One example can be lookup or directory services. The primary function of these services is how to navigate content rather than what content they are navigating. Therefore it is a good idea to separate the library of content from these services and supply the library dynamically

Summary, the moral compass!

These principles as I have stated before should be regarded as virtues rather than laws. Seasoned developers should look at every design decision from the lens of these principles and skillfully apply their wisdom and experience to derive the best software architecture.

This post was created with Typeshare