Top 8 Architectural Principles for Designing Modern Web Applications
The key objective of a software architect is to minimize the complexity of enterprise software system by segregating the design into various areas of concern.
The creation of a well-designed system architecture of large web applications poses immense challenges in the software development process. System architecture design decision can significantly influence the system scalability and maintainability. The success lies in creation of an architectural framework that is responsive to the architectural challenges of these web applications.
A comprehensive understanding of the architectural design principles will help business to manage many challenges ahead faced at the time of implementation.
Ideally these principles will lead businesses toward creating applications out of isolated components that are not closely interconnected to other parts of the application, but rather interact through explicit interfaces or messaging systems.
Separation of Concerns
A key principle of software design, this principle encompasses creation of a system architecture with layered components each addressing a separate concern. The software architecture design created using this principle can be maintained easily ,is less tightly coupled and far less likely to break the Don’t Repeat Yourself principle.
Architecture designed by deploying this principle keeps business logic and rules in discreet location while infrastructure and user interface reside in a separate project. This ensures that iterations in software design do not affect the core business model at the same time the model can be tested easily for its efficacy.
Encapsulation
Encapsulation is defined as the casing up of data inside a single discreet unit. This principle holds together the code and the data it manages. In other words, encapsulation protects the data from being accessed by entities outside the unit.
Software architects utilize this key principle of encapsulation or Object-Oriented Programming using a programming language like Java which lends their code security, flexibility and easy maintainability. This allows the developer to design constructs (objects, functions and classes) that can be declared as a public interface where clients can interact without the internal implementation being tampered or the dependant client code getting affected. Most software developers are comfortable using encapsulation to hide (instance variables) of a class from an illegal direct access.
This hidden data can be accessed only through any member function of its own class in which they are declared. This is popularly known as data hiding.Encapsulation provides a great deal of flexibility to enterprise systems. The entire business process can be overhauled without significant changes in the delivery process. Encapsulation enables OO experts to design agile systems. Systems that are open to change as your business undergoes transformation. A single module of the entire system can undergo changes independently without any impact on any other module of the system.
Single Responsibility
This is one of the most widely applied principles by developers to build robust, scalable and easy to maintain applications. This can be applied not just to classes or microservices but also to software components. Its simplicity is its key feature making the application easier to implement and open to changes in the future.
One of the key considerations is that application requirements change over a period and if your class/ software component has been assigned multiple responsibilities, the more frequently you may need to change it and they cease to be independent of each other.
Don’t Repeat Yourself
Changes effected in one class may necessitate updates or recompilation of the dependant classes. Depending on your change, you might need to update the dependencies or recompile the dependent classes even though they are not directly affected by your change
Consequently, you may have to need update your class more often each change getting more complex. Hence, the single responsibility principle ensures that each class is assigned only one responsibility. Classes, software components and microservices that have only one responsibility are easy to maintain, test or debug and lead to faster deployment.
The Don’t Repeat Yourself (DRY) principle states that duplication in logic should be eliminated via abstraction; duplication in process should be eliminated via automation.
Duplication is Waste
Adding additional, unnecessary code to a codebase increases the amount of work required to extend and maintain the software in the future. Duplicate code adds to technical debt. Whether the duplication stems from Copy Paste Programming or poor understanding of how to apply abstraction, it decreases the quality of the code. Duplication in process is also waste if it can be automated. Manual testing, manual build and integration processes, etc. should all be eliminated whenever possible through the use of automation.
Dependency Inversion Principle
This principle of architecture design deals with High Level Modules of the application which generally involve complex logic. This means they are easily reusable and are unaffected by the changes in low level modules which basically deal with the utility features of the application. An abstraction needs to be introduced to that can decouple the high-level and low -level modules from each other.
An introduction of a simple interface abstraction between the higher-level and lower-level software components eliminates the dependencies between them. The Dependency Inversion Principle enables architects to modify the higher level as well as lower-level components without affecting any other classes if the interface abstractions remain the same. In other words, the principle states that “both the components should depend on abstractions.”
However, it must be noted that the Dependency Inversion Principle is not something that can be used to resolve dependencies instead it enables developers to design an architecture that allows to test various modules of the application in isolation.
Explicit Dependencies Principle:
Strong inter-module dependencies are regarded as an indicator of poor software design. Tightly coupled systems, in which modules have excessive dependencies, are difficult to work with as different modules cannot be studied easily in isolation, and revisions or extensions to functionality cannot be added. Identifying architectural dependencies proactively in the development life cycle along with metrics leads to better communication of architecture quality.
If a component or class relies on other components to accomplish its operations, then the other components are known as the dependencies for this class. Classes or components can have both implicit or explicit dependencies.
This principle of architectural design explicitly declares class- level dependencies at the time of class construction. Most of the time as explicit dependency is an interface which can be exchanged with other implementations at any point in the design life cycle whether in production or during testing or debugging. This principle makes the architecture design loosely coupled, easier to test and accepting of change or enhancement.
Persistence Ignorance
The principle of Persistence Ignorance (PI) holds that classes modelling the business domain in a software application should not be impacted by how they might be persisted. Thus, their design should reflect as closely as possible the ideal design needed to solve the business problem at hand and should not be tainted by concerns related to how the objects’ state is saved and later retrieved. Some common violations of Persistence Ignorance include domain objects that must inherit from a particular base class, or which must expose certain properties. Sometimes, the persistence knowledge takes the form of attributes that must be applied to the class, or support for only certain types of collections or property visibility levels. There are degrees of persistence ignorance, with the highest degree being described as Plain Old CLR Objects (POCOs) in .NET, and Plain Old Java Objects (POJOs) in the Java world.
Bounded Context
Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD’s strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
