OOP, domain models, and the user

Question

When developing domain models, I can see two major ways of thinking about the user:

• The first one assumes that a program is a kind of "simulation" of what happens in the real world, and the user is an spectator. With that approach you would have a Customer class -for example- with perhaps methods that correspond to the actions a Customer can perform. Whenever the customer wants to do something, the corresponding method is called.

• The other approach would be to design the classes as if they were exposed to the user and s/he then has the ability to create and play with the objects "directly", thinking of the program as a kind of extension of the user’s reality. With this approach, a Customer class would probably make no sense as the customer is already "involved".

I've read some articles talking about adding security at the method level, which seems to be consistent with the second approach, but I believe the first approach is far more popular.

What's the best way to deal with this?

Thanks.

• Steven Evers: In the second approach, you'll often see a Customer class instead be represented as a Profile. As is with your example, the user/customer can view and manipulate their profile. It's not clear what you're trying to "deal with" though.
• user3013752: Which approach do you consider better? And why? I personally don't think this is the "choose based on the problem" kind of thing.

Answer 1

Two things pop out at me from this question:

1. the application metaphor (simulation vs API sandbox) has nothing to do with the domain model; until you understand the domain model better that decision should be deferred

2. You'll probably find that your domain model has more than one way of considering the User.

   • Security sees users as a potential threat ;)
   • Data-Processing transactions may see users as Customers and/or Accounts
   • Configuration/preferences elements may see users as owners of Profiles or Preferences
   • feature-control elements may see users as members of permission groups
   • and so on

• user3013752: Thanks, very interesting. What criteria do you use to select the application metaphor? In regards to (2): in my experience if you "split" the user into what you really "have" in real life (accounts, profiles, identities, etc.), this multidimensionality disappears.
• Steven A. Lowe: the application metaphor evolves from the user interaction modes, which is part of the user experience analysis and UI design; can't get that from just the domain model. deciding on the app metaphor prematurely is likely to skew your interpretation of what the users are telling you (confirmation bias will creep in). I suggest letting go of the app metaphor until the domain is understood. If you just can't, then extract the minimum viable product elements (the simplest or most unique things to be done) and prototype them (on paper, mockups, software, etc) and put them in front of the users
• user3013752: I'm sorry, but I'm still confused. The question was: do we design the API (of the domain model library) assuming that the user is the one using the objects and calling the methods, or that a "superior force" uses the models to simulate events occurring in real life? As I see it, assuming either of these positions would have an impact on the design. Do you agree with this? Understanding the domain doesn't really help me decide for one or the other approach. Do you think that the decision is application-dependent? If so, exactly how do you determine which path to take? Thanks again!
• Steven A. Lowe: @user3013752: It's difficult to offer precise advice without more knowledge of the domain. At this point - and with extremely limited knowledge of what you're trying to do - I suspect that the two choices are functionally equivalent, and the distinction largely irrelevant. But perhaps I don't fully understand the question. If this is still an issue (I just saw your response today) please feel free to email me and I'll help if I can.