I'm working on refactoring an older project of mine to follow the Clean Architecture paradigm (and loving it so far) and one of my components is causing me a bit of confusion in relation to whether or not it should exist as a UseCase.

Simple Example For instance, the requirement is there is a contact information screen, that will display previous answers, and give the users the ability to submit updates.

Do I have two use cases (1 user submits contact information, 1 view contact information).

Or is it just 1 UseCase (Edit contact information, with 2 functions to return previous and also submit)?

My Actual Example Bold is the use case i'm not sure about below if you want to skip to that.

The screen itself is a grid of 10 images that you user can select between to have that image featured elsewhere in the application. Nine of These images are resources in the project, one is a spot where a user can upload an image of their own, and the user's selection is stored in Shared Preferences.

Use Cases:

  1. User Selects an Image

    This is definitely a use case and the business logic behind it makes sense to me why. The user is taking an action in the view layer and i'll be updating my data layer (repository) with their selection. Perfect.

  2. User Uploads their own image- This is a use case as well. User uploads their image and do some work to store it, as well as select it as their selection. So two pieces of functionality in one use case, which makes sense. It fits the whole requirement. Perfect

  3. Display Options to User ? - This is the one that is throwing me for a loop. So when the user navigates to this screen, I need to start it by displaying the 10 options for the user to select between, as well as highlighting the previously selected image.So is it a separate use case for me to say Display options, or get options? Or instead, since 9 of these images are in resources, is this just part of my view set up? If thats the case, do I create just a Use Case for retrieving user's uploaded Image?

I know i've got a few other instances like this where there is like an initial data set up set.

Most of the time it comes from an API or the database and it is part of a more complete business rule that makes sense as a UseCase. I'm just a little unsure for cases like this, where maybe i'm reading from a file or loading from some existing resources.

Thanks for the advice!

  • 2
    IME, if you start describing the GUI actions in Use-Cases it leads you down a rabbit hole that never seems to end and it makes your Use-Cases brittle (ie. they become obsolete often). Ignore the user interface entirely. Selecting an image is most definitely NOT a Use-Case. It helps if you think about what you'd call the same activities if they were initiated from a GUI, command line or network interface. If your Use-Cases don't apply for all three interface types then chances are pretty good your Use-Cases are not at the appropriate level and/or are poorly named.
    – Dunk
    Jul 18, 2018 at 20:35
  • It makes sense to keep it away from the UI, however I think the select image is a use case, although maybe my naming conventions need to change? The business requirement is for the user to be able to select an image from a collection, store that image in the database, and then in subsequent screens throughout the application retrieve and display that image. So maybe the use case is something more like, Save personalized background? Or Save Personalization Settings?
    – Kyle
    Jul 19, 2018 at 13:35
  • 1
    'Save Personalization Settings' is much better. Your Use-Case will say something like 'Operator requests to Save Personalization Settings. The system then....'. When you start creating the architecture you'll have a domain object called 'Operator'. The Operator module is the GUI. Let the designer decide the details. Use-Cases aren't meant for that. By keeping those details out of the Use-Case you've made it possible to design the system separately from the GUI(other than defining the interface between the modules). That's what Use-Cases buy you from a design POV. Independent modules.
    – Dunk
    Jul 19, 2018 at 21:30
  • That makes sense. Ok I'll try to frame them like this going forward and see where it gets me. I definitely have some more reading to do to really implement this correctly. But this has been helpful. Thanks!
    – Kyle
    Jul 20, 2018 at 15:56
  • Every person you ask about Use-Cases will have a different opinion on what makes a good Use-Case versus a bad Use-Case. Furthermore, everyone has their own style for writing them and how they make use of them. Don't get yourself bogged down writing the Use-Cases. When you start defining the architecture and even get to design, you'll find things you wish you included, stuff that had no practical purpose and had no need to be included and things you believe should have been worded differently to be more useful. After a bunch of projects you'll should eventually have a useful style 4u.
    – Dunk
    Jul 20, 2018 at 20:22

1 Answer 1


Is it about use case or user interface ?

What you call use case seems to be the detailed specification of a user interface:

  • The screen itself is a grid of ...
  • User Selects an Image ...
  • User Uploads their own image ...

In other words, your focus is more on "how" than on "what". So the first question to ask is what you want to document.

Is it the user interface ?

You could of course use use cases (UC) for this purpose. But they might be a suboptimal overkill: the link between the actions described in the UC and the user interface elements is not clear; In addition, UC are not meant to document an ordered sequence of actions with alternatives.

Spontaneously, I'd rather recommend to use a couple of wireframes to express such things very effectively.

If the user interface is complex, and requires some sequence of actions, you may consider activity diagrams rather than use cases.

Or is it about the system purpose?

Use cases are more effective at describing the purpose of a system, i.e. for what goals the user will interact with the system. The focus should be on the big picture rather than the details.

For example, I understand that the goal of your application users is not to manage and upload pictures nor to fight with grids; the goal is to manage resources (Main use case). Use cases could be decomposed to should what subgoals the user wants to achieve, e.g. what the system shall allow a user to do with resources. Typically it could be things like maintain a catalogue of ressources resources, describe individual resources, allocate resources to projects, etc...

How these use cases will be achieved in the system depends on its design. For instance one could imagine a single screen application that allows to launch all use cases. Alternatively, you could also define a transactional system, in which each use case would have its specific user interface.

Additional reading

I highly recommend you Ivar Jacobson's Use Case 2.0 free ebook. Jacobson invented the use case approach of UML. In this ebook, he clarifies the main intent of use cases, and how they could be used in a modern agile context.

  • I appreciate the detailed answer! It definitely seems like keeping it as abstract and resource focused as possible makes sense. In this case it seems like a good place to start might be a Use Case for Saving Personalization Settings, and a second one for Retrieving Personalization Settings. That way the details of the personalization is left up to the UI, and the way that they're saved (local database, api, etc...) is truly independent. All that both systems know is that they need to save settings related to personalization? I'll look into the reading. Seems like a good place to start.
    – Kyle
    Jul 20, 2018 at 16:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.