Have you ever been to a restaurant with a friend who orders something, but then changes their mind? And before the waiter leaves, they change their order once more? This happens all the time in software development. It’s not anyone’s fault: business is always changing. New ideas for features pop up, laws and regulations change, or users don’t like the way something works. But if you understand that change is an important part of development, it’s easier to not feel frustrated when a request for change happens.
Actors: Users of the System
To help you understand where all this change comes from, we will look at the users of the system and what they want to accomplish. Your goal is to understand the needs of users, from their perspective, so that you can eventually translate those needs into code. This is where identifying actors comes in.
An actor is a role played by anything that uses your system. It will request to perform functionality on its behalf. It is usually a person, but could also be another system, or even the passage of time. For example, you may have to generate a day’s report of transactions for the previous day. This is often set to go off at midnight, or a couple of minutes after. The passing of midnight is conceptually the actor.
Because actors set the system in motion, they are not within the system you are building. They are not modeled in great detail, and you only care about their interactions. For example, a driver interacts with a car, perhaps by hitting the brake to stop, but it's not part of the car.
Within domain-driven design, actors can help identify domains based on what they are trying to accomplish. For example, imagine you have a website where you buy and sell different products. Some actors will be in the same domain because they share the same goals (i.e., clients). Others will be located in different domains because they have different goals (i.e., vendors). So a big part of identifying domains depends on what users are trying to do.
Additionally, identifying actors is a key step in domain-driven design because they can help set priorities for what to build. Paraphrasing George Orwell’s Animal Farm:
“All actors are created equal, some are more equal than others.”
You don’t want to waste time implementing functionality for a low priority actor.
How do I distinguish between high and low priority actors?
Who's paying for the project? 😉 Well, that can be one determining factor. But in reality, high priority actors are based on where you'll find the biggest payoff for the business. Let's look again at a warehouse/e-commerce site. High priority actors would be those who buy things. Any features that help them buy things easier, or buy more things, would jump to the top. A lower priority actor might be someone inside the organization who uses the application for maintenance purposes.
How do you figure out who the actors are in your system? You guessed it - by talking to clients! See if you can identify some actors in the following interview with a developer and two clients. Watch for any mention of someone needing to use the system:
What users have you identified so far? While interviewing the librarians who need to use the system, they are also talking about patrons who will interact with the system. That gives you two actors: patrons and librarians.
To build the system, you've got to figure out what those actors are trying to do.
Use Cases: What Actors Are Trying to Do
Listen to the conversation between the developer and the librarians again. See if you can capture some of the requirements. I'll wait. 🙂
Kind of a lot going on, right? How do you sift through all that information and pick out what's relevant? An easier way is to start by identifying use-cases. Use cases are what actors are trying to accomplish. For example, here are a few from the school example:
Score exams.
Record attendance.
Collect tuition.
Pay instructor.
The concept of use cases comes from Ivar Jacobsen, who was looking for a better way to capture requirements. Previously, this was done from the system’s perspective, rather than the user's. As you saw before, building from the system first, or bottom-up approach leads to problems in the long run. After all, users change their minds quite often, which is why it's better to capture requirements from their perspective.
Wait, don't we need to know more than just the goal to build a system?
Definitely! You start by identifying the goal or goals the user (actor) wants to achieve, and eventually, you'll generate a sequence of interactions between the user and the system, which allows them to reach that goal. But to begin, all you care about are the goals themselves.
Step 1: Define the Goals
Go back and listen to that conversation between the developer and the librarians again. But this time, try to capture the use cases; that is, the goals of the librarians, not all the details. Go ahead and write your use cases down, so you can compare them with the answer later. I'll wait. 🙂
Have you finished? Hopefully, that went a lot easier for you. Here is what you should have discovered:
Generate late book report.
Fine account for lateness.
Purchase replacement book.
Collect patron fines.
"Generate late book report” doesn’t have any details, but at this point, you’re just trying to know what they want the system to do. You’ll worry about how to make it happen later.
What if I miss something?
This whole process is about collaboration. You will have many conversations, and you are bound to miss an item here or there. But you will have plenty of opportunities to reconnect and fill in any gaps.
Step 2: Capture Interactions Via a Use Case Description
It's time to capture some details! Once you've defined the goal of a use case, you need to capture the interactions via a use case description. You can describe these in many ways, but a simple one is to bounce back and forth between the user and the system. For example, let’s come up with a "search for book" use case. You're going to walk through the scenario starting with the user, then think about how the system reacts step by step:
The user requests to search for a book.
The system displays the search page.
The user enters the author’s name.
The system verifies the author’s name exists.
The user enters the title of the book.
The user requests the search executes.
The system searches.
The system displays the results.
Tada! You have a simple use case. You're starting with a happy path, which is a sequence that ends with success.
Wait a minute, how are author’s names stored? What happens if the author’s name can’t be found? Do we offer suggestions?
All in good time - there are still a lot of details to iron out! You will expand this sequence into more and more detail as needed. So yes, you will eventually determine what should happen if you can’t find an author’s name.
Yeah, but when do we do this expansion?
It depends on the project's approach (which is independent of domain-driven design and building domain models). There are many different approaches. As you understand more detail, you could use the agile approach, where more user stories cover the discovered alternative paths. You could then tackle these stories earlier or later, depending on how likely or important that path is.
So in the above example (the user can't find the author's name), a couple of alternative paths might be:
Just show "there are no authors by that name." (Easy to implement, but not very helpful)
Show listings for authors with similar spellings. (Not easy to implement, but very helpful)
But determining which to do, and when, is a project management decision. DDD can't help you there.
Entities: Defining the Concepts in Your System
Finally, examine these scenario interactions and look for long-lasting ideas that make up the entities of your domain model. Currently, there isn’t a whole lot to go on as there's only one use case/story: searching for a book.
Let's look at some possible entities in the use case description above.
The user requests to search for a book.
Well, a user is a long-lived import item, as is a book. So there's a couple entities.
The system displays the search page.
While the system certainly runs the whole time, it is what you are building, and isn't considered an entity. The search page is an implementation detail, so it is outside the domain and is not an entity.
The user enters the author’s name.
Authors are important ideas connected to books. Patrons and librarians refer to them all the time. Sounds like an entity! You would continue this same process until you've figured out everything!
Try It Out for Yourself!
Now that you understand actors, use cases, and entities, let's create a use case description for your librarians, and identify the entities. Here's your challenge:
Create a use case description for "generate late book report." Identify the entities. Scroll past the image for an example!
Solution:
Yours may be different from mine, but here's a possible answer (entities are bold):
The user selects the late books page.
The system displays the page.
The user enters the patron's name or Id number.
The user selects search for late books.
The system searches:
A late book is one that is checked out by a patron, and has not been turned back in before the due date.
The system presents a list of late books.
The user selects print.
The system prints the list.
Was yours similar? 😁
Try to come up with use case descriptions on your own based on the remaining three use cases from the librarians:
Fine account for lateness.
Purchase replacement book.
Collect patron fines.
Once you've got some use cases, practice identifying the entities as well!
Let's Recap!
You've seen how a conversation with users can lead to identifying actors and use cases:
Actors are users of your system.
Use cases are the goals actors want to achieve.
Write out use case descriptions in ever more detail (interactions).
Determine the entities by examining the use case descriptions.
Now you're ready to test your knowledge in the end-of-part quiz!
