This post will talk about popular design principles used in the software architecture world. Architecture is about the decisions you wish you could get right early in a product or project lifecycle.
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 treed 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 the trade-off between quality and cost, the high quality wins, always. Over time, Architectural investment pays off with the ease of developing new features in the short term.
Common Architectural Principles
SOLID Principles:
1. 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.
2. Open–closed principle
- Software entities ... should be open for extension, but closed for modification.
3. 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.
4. Interface segregation principle
- Many client-specific interfaces are better than one general-purpose interface.
5. Dependency inversion principle
- One should "depend upon abstractions, [not] concretions.
KISS (Keep it simple)
Everything should be made as simple as possible.
YAGNI (You aren’t gonna need it)
Do not build it until it is needed.
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.
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 an 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 to use the new construct.
Conclusion
Common design principles mentioned above are the guiding light in software development and provides a very good reference point, but there will always be an exception where these principles may not fully make sense. So, always refer context in which software is being built and then accordingly choose a suitable version of software architecture principles.
Please like, share and comment your views/ opinion in community.
Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.