What are the Key Design principles of Software Architecture ?

Key Design Principles

Separation of concerns

• Divide your application into distinct features with as little overlap in functionality as possible.
• High cohesion and low coupling

Single Responsibility principle

• Each component / module should be responsible for only a specific feature or functionality

Principle of Least Knowledge

• A component / object should not know about internal details of other components / objects.

Don’t repeat yourself (DRY)

• In terms of application design, specific functionality should be implemented in only one component (should not be duplicated)

Minimize upfront design

• Only design what is necessary.
• Especially for Agile development, you can avoid big design upfront (BDUF).

When designing an application or system, the goal of a software architect is :

• To minimize the complexity by separating the design into different areas of concerns like, UI, business processing and data access
•  Components should focus on that specific area and should not mix code from other areas of concern

Application layer principles

Separate the areas of concern

Break your application into distinct features (functionality) that can be optimized independently of other features, so if one feature fails, it will not cause other features to fail.

Be explicit about how layers communicate with each other

Make explicit decisions about the dependencies between layers and the data flow between them.

Use abstraction to implement loose coupling between layers

Define interface components such as a façade with well known I/O that translate requests into a format understood by components within the layer.

In addition, you can also use Interface types or abstract base classes to define a common interface or shared abstraction (dependency inversion) that must be implemented by interface components.

Do not mix different types of components in the same logical layer

Start by identifying different areas of concern, and then group components associated with each area of concern into logical layers.

Keep the data format consistent within a layer or component

Mixing data formats will make the application more difficult to implement, extend, and maintain.

Principles for Components, Modules and Functions

A component/object should not rely on internal details of other components/objects

 - helps to create an application that is more maintainable and adaptable
 

Do not overload the functionality of a component

Overloaded components often have many functions and properties providing business functionality mixed with crosscutting functionality such as logging and exception handling.

 - Very error prone and difficult to maintain

Understand how components will communicate with each other

You must determine if all components will run within the same process, or if communication across physical or process boundaries.
 

Keep cross-cutting code abstracted from the application business logic as far as possible

Cross-cutting code refers to code related to security, communications, or operational management such as logging and instrumentation. Mixing the code that implements these functions with the business logic can lead to a design that is difficult to extend and maintain.

Changes to the crosscutting code require touching all of the business logic code that is mixed with the cross-cutting code.

Consider using frameworks and techniques (such as aspect oriented programming) that can help to manage cross-cutting concerns.

Define a clear contract for components

Components, modules, and functions should define a contract or interface specification that describes their usage and behavior clearly in terms of pre-conditions, post-conditions, side effects, exceptions, performance characteristics, and other factors.