Why is Software Architecture Essential?

In the past, developers often created software without a defined architecture, initially enjoying the benefits of reduced planning overhead and quicker prototyping. However, as development progressed, these systems became rigid and difficult to manage, resembling a "Big Ball of Mud." With increasing costs associated with each modification, this method proved unsustainable.

As projects matured, the escalating maintenance costs and limitations on software evolution prompted developers to devise more robust architectural strategies to prevent the pitfalls of architecture-less designs. The following are some prominent architectural styles:

• Layered Architecture
• Tiered Architecture
• Service-Oriented Architecture (SOA)
• Microservice Architecture

Layered Architecture

This methodology is based on the principle of separation of concerns, structuring software into distinct layers, each dedicated to specific responsibilities. The architecture typically includes:

• Presentation Layer
• Business Logic Layer
• Data Link Layer

The Presentation Layer manages the user interface and is responsible for user experience, being the only layer directly accessible to users. The Business Logic Layer encapsulates the application's core logic, allowing changes in business requirements without impacting the user interface or other layers. The Data Link Layer handles interactions with persistent storage, such as databases, and performs non-domain-specific data processing.

Data and control flow through each layer, enhancing design abstraction and contributing to software stability.

Advantages

• Easier to implement compared to other models.
• Provides abstraction through separation of concerns.
• Modifications in one layer do not affect others.
• Reduced coupling improves manageability.

Disadvantages

• Limited scalability.
• Tends to produce monolithic structures, complicating modifications.
• Data must traverse through each layer, even when unnecessary, leading to a Sinkhole Problem.

Tiered Architecture

This architectural style segments the software system based on client-server communication principles. It can be structured as a single-tier, two-tier, or n-tier system, defining responsibilities between the data provider and the consumer.

It employs a Request-Response communication pattern, offering scalability both horizontally (adding high-performance nodes) and vertically (enhancing individual node capabilities).

#### Single Tiered System In this setup, a single system acts as both client and server, simplifying deployment without inter-system communication, thus enhancing speed. However, it is only suitable for small-scale applications.

#### Two-Tiered System

This system comprises two physical machines, one acting as the client and the other as the server, isolating data management from data processing and representation tasks.

• Client: Contains the Presentation, Business Logic, and Data Link layers.
• Server: Hosts data stores like databases.

#### Three-Tiered / n-Tiered System

This architecture supports high scalability in both dimensions and is often more expensive to implement, making it suitable for large, complex software solutions. It can integrate with advanced service-oriented architectures for sophisticated models, recommended for performance-driven software.

Service-Oriented Architecture (SOA)

SOA is a service-based architectural model enabling components and applications to communicate via well-defined services. It consists of five key elements:

• Services
• Service Bus
• Service Repository (service catalog)
• SOA Security
• SOA Governance

Clients send requests through standard protocols and data formats over the network. The Enterprise Service Bus (ESB) orchestrates and routes these requests to appropriate services using the service repository. The response may involve interactions with other services or databases, all under SOA governance and security guidelines.

Services can be classified into two categories:

1. Atomic Services: Provide functionalities that cannot be further decomposed.
2. Composite Services: Aggregate multiple atomic services to deliver complex functionalities.

Types of Services

Services can include:

• Entity Service
• Domain Service
• Utility Service
• Integrated Service
• Application Service
• Security Service

Microservices Architecture

As defined by Martin Fowler in 2014, Microservices architecture is:

> "The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery."

This architecture emphasizes service componentization, breaking down the software into distinct, isolated services, each responsible for a single function. Changes in one service should not impact others.

Components of Microservices

The architecture comprises:

• Services
• Service Bus
• External Configuration
• API Gateway
• Containers

Characteristics of Microservices

Microservice Architecture should exhibit the following traits:

• Componentization through services.
• Organization around business capabilities.
• Products, not projects.
• Smart endpoints with dumb pipes.
• Decentralized governance and data management.
• Infrastructure automation.
• Design for failure.
• Evolutionary design.

It's advisable to allow different teams to evolve various microservices independently over time, akin to bubbles in the air. Since data communication occurs through standard protocols and formats, changes to one service won't disrupt others.

Advantages

• Low coupling due to high isolation.
• Improved modularity.
• Failures in one service don’t affect the entire system.
• Enhanced flexibility and scalability.
• Faster iterations due to easier modifications.
• Better error handling capabilities.
• Avoids the Sinkhole Problem of layered architecture, ensuring data flows through relevant services only.

Disadvantages

• Increased risk of communication failures between services.
• Challenging to manage numerous services.
• Issues like network latency and load balancing must be addressed.
• Testing can be complex in a distributed environment.
• Implementation may require significant time.

References

• https://divante.com/blog/monolithic-architecture-vs-microservices/
• https://www.udemy.com/course/software-architecture-and-design-essentials/
• https://martinfowler.com/microservices/

Conclusion

Each software architecture approach is crafted to address the specific challenges faced by its predecessors. Understanding these various methods enables you to design an effective architecture tailored to your project's needs.

> “While no perfect software architecture exists, any approach can be deemed relatively ideal if it meets the functional and non-functional requirements of the project.”

Join Medium membership for unlimited access to insightful content.

You May Also Like

• Common Mistakes in Software Product Development
• Why Microservices Aren't Always the Best Choice
• Working with New Generation of Python
• Why Kotlin and Swift Are Siblings?
• Understanding Dynamic Polymorphism in C++
• Exploring the Latest in Java Development