What is software architecture?
A step before coding that looks to ensure that the project will meet all the requirements and also have high quality. Refers to the structure of a program, meaning implementation details aren’t relevant. Public interfaces are the main focus of Software Architecture. It tries to explain relationships between the project’s modules.
As the Software Engineering Institute puts it:
“The software architecture of a program or computing system is a depiction of the system that aids in the understanding of how the system will behave.”
Behavior is the keyword in that definition. There are many ways to achieve something in programming. Some of the variables included are language, structure, modules, and way of communication. Most companies tend to change at least one of the previously mentioned aspects but, when trying to achieve the same thing, behavior remains a constant.
As with many other concepts, there are some principles that are considered key when doing software architecture. According to MSDN, they are:
- Separation of concerns. Divide your application into distinct features with as little overlap in functionality as possible. The important factor is minimization of interaction points to achieve high cohesion and low coupling. However, separating functionality at the wrong boundaries can result in high coupling and complexity between features even though the contained functionality within a feature does not significantly overlap.
- Single Responsibility principle. Each component or module should be responsible for only a specific feature or functionality, or aggregation of cohesive functionality.
- Principle of Least Knowledge (also known as the Law of Demeter or LoD). A component or object should not know about internal details of other components or objects.
- Don’t repeat yourself (DRY). You should only need to specify intent in one place. For example, in terms of application design, specific functionality should
implemented in only one component; the functionality should not be duplicated in any other component.- 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 very high. In other cases, especially for agile development, you can avoid big design upfront (BDUF). If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. This principle is sometimes known as YAGNI (“You ain’t gonna need it”).
These principles deal mainly in how the code should be structured and how programmers should work on it. The last one also deals with what should be worked on as the project advances. Programmers should focus on the clear requirements of the program and not lose themselves writing code that may not make it to the final version. Extra features won’t make a program better if the core functionality isn’t there.
