Software Architecture - Five Common Design Principles

#architecture

This post will talk about popular design principles - used in Software architecture world, which are time-tested and even relevant today.

What is Software Architecture?

Software Architecture is the shared understanding that the expert developers have of the system design.

In other words described by Ralph Johnson & Martin Fowler, Architecture is about the decisions you wish you could get right early in a product or project lifecycle. Architecture is about the important stuff, whatever that is.

To draw an analogy with tree for ease of understanding, Architectural investment builds new and stronger branches. Features put leaves on branches.

Software with well-defined architecture leads to good quality software and that leads to high velocity over time. Considering trade-off between quality and cost, the high quality wins, always. Over time, Architectural investment pays off with ease of developing new features in short time.

Common Architectural Principles

SOLID Principles

S - Single-responsibility principle - A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.

O - Open–closed principle - Software entities ... should be open for extension, but closed for modification.

L - Liskov substitution principle - Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. Design by Contract.

I - Interface segregation principle - Many client-specific interfaces are better than one general-purpose interface.

D - Dependency inversion principle - One should "depend upon abstractions, [not] concretions.

KISS (Keep it simple)
Everything should be made as simple as possible. As Simple as this, nothing complicate, Design systems to be simple and easy to understand and maintain.
YAGNI (You aren’t gonna need it)
Do not build it until it is needed. There are lots of envisioned features, which are not needed on priority, leave them aside. At the same time, having view of what is coming will actually set the right direction of solution.
Opportunity Cost Principle

Opportunity costs define what we have to give up in getting that value. For the highest value, we should always opt for the option that offers maximum benefits at the lowest cost.

Always weigh down different options against one another. Choose a path that adds maximum value to the project.

Don't repeat yourself (DRY)

Avoid specifying behavior related to a particular concept in multiple places within application. As this will lead to a frequent source of errors. At some point, a change in requirements will require changing this behavior. It's likely that at least one instance of the behavior will fail to be updated, and the system will behave inconsistently.

Rather than duplicating logic, encapsulate it in a programming construct. Make this construct the single authority over this behavior, and have any other part of the application that requires this behavior use the new construct.

Conclusion

Common design principles mentioned above are guiding light in software architecture and provides very good reference point. But there will always be exception cases where this principles may not be applicable in its pure form, So always refer context in which software is being built and then accordingly choose suitable version of software architecture principles. There are just a few common set of time-tested software architecture principles, list can go on and on with cloud and other modern technologies.

Enjoy architecting software systems and make them secure, reliable, highly efficient and cost effective.

Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.