Layered Architecture

In the previous pages, we decomposed a software product horizontally into use cases. In this page, we look at a second, complementary form of decomposition: layering.

Use cases answer the question: “What business responsibilities does the product implement?”

Layers answer a different question: “What type of work is being performed?”

Layered architecture does not introduce new responsibilities. It organizes existing responsibilities so they can evolve independently.

Why Layers Are Needed

A single use case typically requires several different kinds of work:

• Handling the current business process state
• Making business decisions
• Preparing data for decision-making
• Accessing data stores

If these responsibilities are mixed inside the same components, the use case becomes hard to maintain and hard to test. Changes in one concern create unintended effects in others.

Layering separates responsibilities by their nature. It keeps each type of work in its own conceptual place.

The Logic Layers

In this book, the functional architecture of a business software product naturally forms four logic layers:

• State logic layer – selects the state handler for the current business process state.
• Business logic layer – evaluates outcomes and chooses the next state.
• Data processing logic layer – transforms raw data into decision-ready information.
• Data access logic layer – performs CRUD operations against data stores.

The diagram below illustrates these layers and the direction in which responsibilities flow.

Direction of Dependencies

Layered architecture is not only about grouping code. It is also about keeping dependencies under control.

A simple and useful rule is:

• Higher layers may depend on lower layers.
• Lower layers must not depend on higher layers.

This rule prevents circular dependencies and protects business behavior from being entangled with infrastructure details.

Layers and Use Cases Together

Use cases and layers do not compete. They stack.

• Use cases provide horizontal decomposition by business responsibility.
• Layers provide vertical decomposition by type of work.

This means a single use case may contain components from multiple layers. At the same time, a single layer may contain components belonging to many use cases.

The intersection of these two decompositions is what forms a practical software architecture.

Why This Matters

When use cases are isolated and layers are respected:

• Business changes remain localized.
• Testing becomes simpler because responsibilities are separated.
• Components can be replaced or distributed without redesigning the business model.

Layering is therefore not a stylistic preference. It is a structural technique that preserves clarity as systems grow.

Table of Content Software Architecture Previous: Use Cases Architecture Next: Functional Architecture

 

---

Business Process Programming in .Net
© 2004–2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness or suitability of the information and are not responsible for any damages resulting from its use.