The Case for Using Use Cases In Code
I was in a quandary. I hadn't come across a similar situation before. What was the best way of handling this?
About 20 years ago, I was working as a developer, and I came across an unusual situation. It became for me the seed of a beautiful learning experience.
OK, here is what happened. The firm I was working for at the time had a collection of web services. One of those web services performed background processing when called with a simple HTTP GET call. A timed scheduler program would make the call to the web service every hour to kick off the processing.
Now, the decision had been made to move this web code into a Windows Service where it could be scheduled to run at regular intervals without the need for the HTTP request. In those days, when Windows ruled supreme, it was the norm to employ a Windows Service for regular processing of background tasks.
The task fell to me to implement this change; move the code from the web service to the Windows Service. No problem. I had experience developing both web and Windows services. This change appeared a simple one. Innocently enough, I estimated it would take me only take 2-3 days.
As soon as I had copied and pasted the code from the web service into the Windows Service, there were numerous compilation errors. Way too many - Hundreds.
Silly me. I had thought the code would compile and work almost right away.
I had not considered that in a Windows Service, there was nothing 'web'. For example, the usual web constructs I was familiar with like HttpRequest, HttpResponse and HttpContext did not exist at all!
Cutting a long story short, I remember that it took me nearly a fortnight to get the code working again. This time in a non-web context.
Once all the dust had settled, a question as forming in my head:
Was it possible to structure code in a such a way that it could be picked up, without altering it, and moved to another delivery mechanism and it would work?
In other words, code that would build and run whether it was in a web service, Windows Forms application, console app, or anything else.
Unfortunately, I didn't dwell on the question and go looking for a solution. At the time, I might have thought it an impossible pipedream.
Fast forward to 2012. I learned about Robert C. Martin, aka Uncle Bob.
In one of his videos, Uncle Bob espouses the notion of encapsulating high-level business logic in something called an 'Interactor'.
These Interactors were to be the entry point to the Business Logic code.
OK, what does this mean?
______________________________________________________
Business Logic Primer
The Business Logic of a system is WHAT needs to be done to achieve the desired business objective.
Example: Loan Application Process
An overly simplified process to apply for a personal loan with a bank might run along the following lines:
- Receive loan application form
- Check form for completeness
- Check customer's creditworthiness
- Check customer collateral
- Register customer
- Register customer loan on loan book
- Pay loan money to the customer
Notice that the process described above would also work if done with paper, rather than computer code, the way lenders did it a century or more ago.
This step-by-step process describes WHAT needs to happen, not HOW it is to happen. Notice how there is no mention of Web - Web could be one delivery mechanism. There are others; paper, mobile, clay tablets.
The point is that at the highest level of WHAT a system does the delivery mechanism is unimportant.
______________________________________________________
OK, Let's return to Uncle Bob's Interactors, the high-level entry points to Business Logic when expressed in computer source code.
Maybe a more intuitive name for Interactors could be Use Cases.
Some readers might remember Use Cases from Unified Modelling Language (UML). In the 1990s and a bit after, UML was a popular tool to model software systems.
For example, in object-oriented source code, we should express the above loan application process as a Use Case class. We would then be able to host this class in a Windows Service, a Web app, a Windows Forms application, or any other delivery mechanism.
Very powerful. Something to ponder on.
Conclusion
Use Cases are not only a UML construct. Their use in code creates an abstraction that allows the migration of high-level business logic from one delivery mechanism to another with relative ease. The first step in the ability to create pluggable systems.
Next Time
We'll delve deeper into Use Cases. We'll examine the code for a Use Case class. We'll discover how Use Cases delegate action to other, lower-level components. We'll examine how Use Cases classes provide independence from particular database technologies and services.
Principal Engineer at Empower
5 å¹´Nice article, take a look at Uncle Bob's Clean Architecture which is a bit more of the HOW part.? I use a similar approach to his called the Onion Architecture but it all follows a similar path of outside in to the domain. This helps keep the environment you are running in mostly isolated from the use cases and domain logic.? I also like the concept of CQRS in it's purest form (without event sourcing) to help drive the concept of use cases and where/how to handle such a concept.? ? ? ?https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Very well explained, good stuff!