Use Cases Architecture

In previous chapters, we learned to look at a business process as a structured set of activities and states. A complex business process is rarely implemented as a single block of logic. Instead, it consists of smaller, logically independent subprocesses.

Each subprocess:

• Handles a specific business concern
• Operates on a well-defined set of business entities
• Has its own internal states and transitions

In software architecture, these subprocesses become use cases. A use case is the architectural unit that implements a business subprocess.

This means that, architecturally, a software product is a set of use cases working together to implement a business process.

Use Case Isolation

One of the most important properties of a use case is isolation.

Isolation means that the functionality provided by one use case does not depend on the functionality provided by another use case.

Each use case:

• Can be designed independently
• Can be implemented independently
• Can be tested independently
• Can evolve independently

This property is what allows use cases to become stable architectural building blocks.

Entities and Responsibilities

A practical way to identify use cases is to follow the business entities that the process operates on.

In the dental receptionist example, the business process works with entities such as:

• Patient
• Identity document
• Appointment
• Visit

Each of these entities participates in a distinct business subprocess. That subprocess becomes a use case.

Use Case Structure

Architecturally, a use case is not a single component. It is a coordinated set of components responsible for:

• Handling business states
• Executing transitions
• Applying business rules
• Processing and accessing data

Why This Matters

When a software product is organized around use cases, its architecture reflects the structure of the business process itself.

This alignment makes the system easier to understand, easier to change, and easier to distribute.

Use cases are the point where business structure becomes software structure.

Table of Content Software Architecture Previous: Distributed Architecture Next: Layered 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.