What Is A Use Case?

What is the essential part of a computer system?

Answer: The reasons for the system’s existence: What does it do? What problems does it solve? How does it add value to its users?

In the modern business world, computer systems automate necessary processes that used to be done manually by people. Computers, especially software systems running on computers, have taken over and are now doing the work.

Each separate step-by-step procedure encoded into a computer program achieves a useful and valuable objective. For example,  

• Pay for goods in a shopping cart, or
• Generate invoices, or
• Amend orders, or
• Register a customer,
• etc.

These procedures consist of multiple logical and required steps, each getting us closer to our objective of unlocking business value. For example, when a new customer registration has been completed, the business can sell goods and services to the new customer. 

Use cases are business logic workflows encoded into computer programs.

Use cases describe WHAT the business wants to do to unlock value, not HOW to do it. For example, the business needs a computer system to generate invoices. That’s the WHAT. The HOW is concerned with the mechanistic details of the computer system: We’re using a Cosmos DB database, and we’ll run the backend system as a web services API secured with OAuth2. At the same time, the client will be a mobile app written in Kotlin.

We get a handle on the use case (the WHAT) by writing out the step-by-step business process without mentioning any technologies and ensuring it could also describe the previously manual or paper-based process. 

For example, in a budgeting application, the steps to import the latest transactions for a given bank account number could be described as follows:

A Use Case for importing bank account transactions:

1. Get the most recent transaction for this bank account number from our transaction repository.
2. Get all the latest, new transactions (in date-order after the most recent transaction determined in Step 1) for the account from the bank.
3. Record those new bank account transactions in the transaction repository.

Notice how this multi-step use case description lacks all technical details, such as what database we’d be using, and it would therefore work for a computer program and a manual workflow. Someone may transcribe bank account transactions from paper-based bank account statements to a separate paper ledger (the transaction repository). For an automated computer program, acquiring new account transactions could involve scaping the bank account info from the bank’s website or reading it from the bank’s API. 

Use Cases are pure WHAT (i.e. the objective) we’re trying to achieve without any HOW (i.e. technical detail) we will achieve it.

It’s worthwhile keeping in mind that use cases are only complete, value-producing business logic workflows. From time to time, I see programmers assign individual steps within a use case as sub-use cases. For example, sending a notification message to a system admin that a customer has registered may be one such case. However, this sub-step of sending the message will not be a use case in its own right, as it delivers only value in association with all the other new-customer-registration steps. By itself, it is useless and adds no value—why would we want to send a new customer registration message outside a customer registration workflow? Well, we wouldn’t. 

Use Cases, along with Domain Entities and Domain Services, live squarely at the centre of the Clean Architecture and therefore are of the utmost importance to application design.