I recently read this article about Clean Architecture, as I'm trying to get out of some usual OO habits (interface design everywhere, but what does it do???), and program something that describes what the system does instead of how the system is built (to paraphrase "Uncle" Bob).

Once that article gets to the use case layer, the author mentions he left users until that layer because users are specific to the application, then makes a reference (that I really don't think I got) to how if it were a board game it wouldn't have users, but it would still have all the domain objects, in his case orders and products.

But the way I see it, in a web app (some light SaaS) users are part of the domain. Imagine a cloud document store like Dropbox: they store documents, so it seems a document is definitely a domain object. But they also have users don't they? Their business involves storing documents for users, and without users wouldn't that violate an aspect of their business?

I just don't get why users aren't considered part of the system in the same way documents or other things are. Can someone clarify this principle and the reasons behind it for me?

1 Answer 1


The author makes the distinction between what is in the "board game" or not with the following example:

eBay the website and eBay the board game both need buyers, sellers, items, and bids – but only eBay the website needs users, sessions, cookies, login/logout etc.

See how he mentions "buyers" and "sellers"? These are just different names for "users", but put in the context of the business.

The main point of the separation is that your business model (or as Uncle Bob puts it, "application agnostic business rules") do not need to know about the current user's authentication and authorization methods, or that it has a password, or uses Facebook or Google. Back to the eBay example, the business only needs to know that, in the context of the Order X, user Y is the buyer while user Z is the seller. This is what's important to make the business run - this is what the application does.

Always remember that the idea is to make the business rules completely agnostic of the delivery mechanism. You may have Users as part of your business model, there is nothing bad about it - Dropbox certainly needs, as you pointed out. But be sure to strip away anything related to how the user interacts with the system. This level of detail can be dealt with mostly by the delivery mechanism, and in some part by the application-specific business rules.

For instance, in some apps I've made, I check the user's authorizations within my use-cases, but the authentication methods are decoupled as plugins to be implemented from outside the applications. This has allowed me to easily add login options such as Faceebok, Twitter and Google, without affecting the structure of the applications.

  • Hmm, I suppose I just got myself confused, but if there is no distinction in your application, is it ever permissible to put "users" in the domain level using clean architecture? Or is it just not done?
    – Adam
    Commented Dec 8, 2014 at 3:26
  • 1
    Yes, as long as it's just the "User" from the business perspective, striped of anything web-related. That's what I meant when I mentioned Dropbox Commented Dec 8, 2014 at 3:34
  • @MichelHenrich already said it really well, and there is only some minor details/clarifications which I probably can add. The problem is that with the word "user", one tends to think of the human being in front of the computer. But the human being is, for example, a buyer - a "user" is only a technical element. I guess we could use other words, "account" for example. An account doesn't buy stuff, buyers do. And buyers have an account as a vehicle to interact with your software. The account then e.g. knows about the username/password, and is of course linked to the buyer entity. Commented Jul 12, 2016 at 9:49
  • @MichelHenrich so where to save the user’s password? Where do I save all those details specific data? And how I connect the to the costumer? Commented Jan 5, 2020 at 15:23

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.