5 principles to follow when designing the architecture of your application

When designing an application or system, architecture is essential. The era of “just code right away” is simply over. In the modern context of software development, architecture plays an irreplaceable role because it determines not only the backbone of a system, but also how the software could be maintained and expanded.

How can you build a high-quality app within budget without compromising your vision? View our Hapsnap Case Study here

The goal of a software architect is to minimize the complexity by separating the design into different areas of concern. Understanding the importance of architecture design will help you overcome countless obstacles when designing a software and also when working with a team of developers.

These are the 5 principles that you should follow when designing your application:

1. Separation of concerns (SoC): separate your application into different sections, and each section will address a separate concern. 
2. Single Responsibility principle: Every module within an application could only answer a single question and be responsible for a single functionality.
3. Principle of Least Knowledge (Or Law of Demeter): An object should have limited knowledge about other objects. This is to avoid getting your objects tangled with each other, especially in applications that have multiple layers.
4. Don’t repeat yourself: You should only need to specify your intentions in one place. For example, in terms of application design, specific functionality should be implemented in only one component; the functionality should not be duplicated in any other component.
5. Minimize upfront design: Only design what is necessary. In some cases, you may require upfront comprehensive design and testing if the cost of development or a failure in the design is exceptionally high. In other cases, especially for agile development, this principle will help you avoid big design upfront (BDUF). If your application requirements are unclear, or if there is a possibility of additional design over time, you should avoid making a huge premature design effort. This principle is sometimes known as YAGNI ("You ain’t gonna need it").

Figure 1 illustrates common application architecture with components grouped by different areas of concern.

(Source: https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658124(v=pandp.10))

Using Good Practices For Your Architecture

By applying these principles, architecture will help software developers better understand the interaction between different components of a system. This will provide a better overview and as much as possible, helps prevent malfunctions occurring later. With detailed documentation about how the architect has built the structure of a project, the team helpfully has a consistent way of implementing changes to the system if needed. And that’s invaluable.

This is essential for not only the architect of the project but also for every developer involved especially in projects with big scope. For example, when working with Scrum methodology, a big project will be divided into smaller ones and each part can be considered a separate project. All of these small projects should follow a standardized database, protocol, framework, reusable codes… But they can only interact successfully with each other if the architecture of the big project is strong enough.

Even though software architecture and software design can overlap in some regards, by giving a bigger picture of elements and interaction, architecture analysis will focus on finding the flaws in a system. Two common flaws that can be detected much easier thanks to a solid architecture are:

-      Flaws in the design

-      Flaws in the implementations (bugs)

Many projects are considered failures because wrongly detected issues leads to inefficiency in production. One of the most common causes for this problem is inconsistencies in design patterns within each layer of an application. Design patterns are helpful when solving small, recurrent issues in development, but if they are not standardized and applied properly, unnecessary complexity will be added to the project. By laying out which design pattern a component should use, a good software architect can help prevent chaos from happening when multiple issues happen later on.

Architects in general often have a higher-level view of a system/application. When working with different languages, they have to understand architectural elements so their solutions could solve not only language-level problems but also system-level problems. A good practice for architects is presenting the architecture in design elements. Only after defining design elements and their interaction/interdependencies they could assign corresponding tasks to those elements. One tool to support an architect when working with designing the structure is Design Structure Matrix (DSM, also known as Dependency Structure Matrix). 

Figure 3 Design Elements as matrix of interdepedencies

(Source: The Art of Software Architecture – Design Methods and Techniques, Chapter 3 – Identifying Design Elements and Their Relationships)

DSM is also useful as a management tool, by providing a compact and clear image of the whole system and its elements. A Project Manager could use DSM to gain insightful feedback and change processes if and when necessary. For example, when you want to implement changes to a component, it is always better if you can immediately identify how those changes could affect other components in the project, before effecting the change.

At Niteco, we practice what we preach, ensuring that at the start of every project, our architects follow these five principles. With decades of successful complex project delivery experience under our belt, our projects are proof these principles get results.

But the proof as they say, ‘is in the pudding’ - check out our latest case studies here, then get in touch with us to see what we can do for you.