Use Cases Architecture

In previous chapters, we learned to look at a business process as a structured set of activities, states, and responsibilities. We also learned that a complex business process can be decomposed into smaller, logically independent parts.

Use cases are the architectural expression of that decomposition.

A use case is not a screen, not a database table, and not a technical feature. It is a coherent fragment of a business process that can be implemented independently.

From Business Process to Use Cases

A complex business process is rarely implemented as a single block of logic. Instead, it is naturally divided into smaller business subprocesses.

Each subprocess:

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

Such a subprocess can be represented as a use case.

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

Use Case Isolation

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

Isolation means that the functionality of one use case does not depend on the internal implementation of 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 candidate use case.

This does not mean that a use case is limited to CRUD operations. CRUD is only a subset of actions performed within a use case.

A use case encompasses all business actions required to process a particular aspect of the business domain.

What a Use Case Contains

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

These components follow the same logic-layer separation introduced earlier in the book.

From a deployment perspective, a use case often maps to one or more assemblies that together implement a business subprocess.

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