Avoid This Simple Software Architectures for Solving Complex Problems

You’ve joined a company excited to tackle a project with complex software architecture. But as a junior developer, you soon realize how hard it is to learn, maintain, and scale. When new requirements arise, implementing them becomes cumbersome and error-prone. It’s easy to think that a simple architecture might be the solution, but simplicity isn’t always enough to solve complex problems.

Everyone wants simplicity. Customers, for instance, love services like "Buy Now, Pay Later"—a simple way to shop without worrying about payment. What’s hidden behind this simplicity, though, is a complex system that manages loans and installment financing.

Simplicity is tempting, but opting for an overly simplistic system design for complex problems can lead to bigger issues down the road. While simple architectures work well for MVPs, what happens when your business needs to solve more than just simple problems?

Definition of Simple Architecture

What is Layered Architecture?

In many software projects, layered architecture is a simple, commonly used approach. It divides the system into distinct layers, each with a specific responsibility. These layers typically include:

• Presentation Layer:
  
  This layer handles external interactions. In frontend (FE) projects, it deals with the UI and user input. In backend (BE) projects, it typically handles API requests and responses (controllers).

• Business Logic Layer:
  
  The core of the system, where business rules and logic are implemented. This layer focuses on fulfilling stakeholder requirements, abstracting away technical details.

• Persistence Layer:
  
  Responsible for interacting with storage systems (like databases). It usually contains functions or methods for reading from and writing to databases.

• Database Layer:
  
  This is where your data resides. Whether it's a relational database, NoSQL, or in-memory database, this layer manages data storage, schema design, indexing, and keys (such as in Redis).

How It Works

Layered architecture follows the separation of concerns principle, meaning that each layer is responsible for its specific tasks. The layers are technically partitioned—each group of components solves a specific technical role within the system.

One of the key rules in layered architecture is how components interact across layers. Notice in diagram below, where Services component is interacting to Entity, then Entity is interacting to Value Object.

Typically, components in a higher layer (e.g., Presentation) can access components in the layers below (e.g., Business Logic or Persistence), but lower layers cannot directly call higher layers.

However, in practice, challenges arise. For example, you may run into issues where components from different layers need to communicate, or you might be tempted to skip a layer to make development more convenient (e.g., bypassing the Business Logic layer to directly query the database).

While this architecture is intentionally simplistic, it works well when a project is starting out, as the clear separation between layers makes it easy to organize and manage the application.

When to Use (and When Not To) — Practical Tips

1. It is good for starters.
   
   Layered architecture is an excellent choice for beginners due to its simplicity and clear structure. It provides a solid foundation for understanding basic architectural principles without overwhelming complexity.

2. Use it on small to medium-sized applications.
   
   This approach works well for applications that don’t require extensive scalability or performance optimization. For small to medium projects, it ensures maintainability and straightforward implementation.

3. Clear, well-defined separation of concerns.
   
   The architecture promotes a clean separation of concerns, with each layer focusing on a specific responsibility. This makes the codebase easier to understand, test, and maintain.

4. Avoid it for complex systems with evolving requirements.
   
   Layered architecture struggles to adapt to complex systems with dynamic and growing requirements. Its rigid structure can lead to bottlenecks and difficulty scaling as the project evolves.

5. Not for high-performance apps.
   
   Applications requiring high performance may outgrow the layered approach, as the additional abstraction layers introduce latency and can become a limiting factor under heavy load.

6. Prevent using it for systems with dynamic needs.
   
   Systems with rapidly changing or unpredictable requirements demand flexibility, which layered architecture lacks. It is best suited for stable environments where requirements are well-defined.

My Thought on Layered Architecture

After the microservices hype, simple architectures gained attention. At first people use microservice as a silver bullet, making a lean engineering team to manage dozens of services that could be handled with a more straightforward layered architecture. This again created a misunderstanding, where layered architecture was seen as a one-sizes-fits-all solution, without considering how projects could evolve into more complex systems over time.

In some cases, teams are tempted to apply a simplistic design to an already complex problem, which can backfire as the project grows. Understanding the limits of simplicity is crucial, as it might lead to difficulties down the line.

My advice: understand when simple architecture is appropriate and, just as importantly, when it isn’t. Knowing the right time and context for applying this approach is key to managing complexity in evolving projects.

Let’s continue the discussion in the comment section, on why layered architecture is not suited for complex problem 🙌

Conclusion

While a simple layered architecture can work well for smaller applications or well-defined problems, it is not a one-size-fits-all solution. As software problems grow in complexity, the need for a more flexible and scalable architecture becomes apparent. If you're working on a complex system, consider adopting an architecture that supports flexibility and scalability from the beginning.

Are you working on a system that could benefit from a more complex architecture? Share your experience in the comments or reach out to discuss how you can optimize your software architecture for the challenges ahead.