Separate "User" and "Customer"

[kingcrunch]

Just a suggestion and I want to know, what you think about it: I would prefer a separate User (ideally simply based on vanilla FOSUser-entity) and Customer-class.

"Something like"-UML

--------                        ------------
| User |  {0,1} <---------> {1} | Customer |
--------                        ------------

• Simplify integration into existing apps, that maybe wants to use their own customized User-implementation.
• For example in Germany it is in some cases not allowed to automatically create an account for a one-time customer. The reason is, that for this customer you are not allowed to save their private data much longer as it is required for handling the process (shipping and so on). This is usually around half a year, or year, or something like this (also affected by merchant warranty, ...). Separating both User and Customer would make it easier to handle this situation: All in one class would mean, that you have to test, whether or not this account was created intentionally, or only to handle the process.
• I think it is simply a cleaner separation 😄

[ghost]

It might be good to see how vespolina does it also.

[kingcrunch]

As far as I could see vespolina doesn't provide something like "customer" or "user" at all. The most identity-related data seems to be "address".

Must say: Seems valid too ^^

[marcospassos]

+1 for this separation once it allows easily implementation of guest checkout and lazy registrations.

[pjedrzejewski]

I like this. If anyone wants to work on this separation, we should start a discussion about implementation first. Thanks @kingcrunch for raising this idea! 👍

[jjanvier]

@pjedrzejewski I can take it,. To do list :

• create a CustomerInterface
• create a Customer entity which extends CustomerInterface with :
  • all the User attributes that do no come from FosUserBundle
  • a one-to-one unidirectional relationship to User
• edit the User entity to remove the attributes moved in Customer
• modify all the "my account" stuff to retrieve data from Customer instead of User

Is it OK for you ?

[marcospassos]

@jjanvier I've some doubts if this separation sounds good from a modeling perspective. In the real life, the user and customer are the same. Furthermore, for the guest checkout case, we can have consumers without users. It may be that naming as Customer isn't the best choice, so it sound confusing for me. What do you think?

[pjedrzejewski]

@marcospassos I think we're talking here about "Customer" not "Consumer". :)

[marcospassos]

Just a typo (fixed), but I keep my considerations. Does it make sense to have two entities, one called User and another Customer? IMHO an user may be a customer but never has one.

[jjanvier]

Just to be cleared, in my mind :

• a User is the person who buys something on the site. This person could be (maybe) a guest in the future.
• a Customer is a registered User. He has several "profile" information such as first name, last name and addresses.

I agree that the names of these entities do not make sense. We could find better. And yes in the real life, a user is a customer (or a customer is a user). But about the separation of these entities @pjedrzejewski @marcospassos, I thought the goal was to decouple profile data from basic user data to be able to use something else that FosUserBundle. Did I misunderstood ? Because marcospassos makes me doubt ^^

[marcospassos]

No, I totally agree with this separation. My point is just about ubiquitous language and cohesion.

[jjanvier]

OK. What about ?

• for the basic data (entity that extends FosUserBundle)
  • User
  • Customer
• for the extended data (the new entity)
  • Profile
  • PersonalInformation
  • CustomerProfile or UserProfile
  • CustomerDetails or UserDetails

[arnolanglade]

What do you think about add custom properties to Customer (like product)? The shop administrator could mange them in the backend, it permit to ask more informations to those Customer like birthbay, etc... Useful for businessmen, they could know their customers a little bit more.

[marcospassos]

@Arn0d it's beyond the scope of this discussion (...and it can be made independent of this separation ;)

[arnolanglade]

@marcospassos : ok sorry.

[jjanvier]

@pjedrzejewski @marcospassos any opinion about the name of the new entity ? UserProfile would be the simpliest no ?

[kingcrunch]

a Customer is a registered User. He has several "profile" information such as first name, last name and addresses.

Just to point that out: My point in this ticket actually was, that a customer is not necessarily a user. A customer may have a user profile (where User and UserProfile are slightly overlapping, if not equivalent) and the other way around a user may be associated with a customer (profile).

For example a user doesn't need a real name, as this is not required to handle the user itself, but the customer needs it.

I'd just create a Customer and create an optional association between this and User. The customer holds the address (and so on), the user only the email, login and so on.

[marcospassos]

@kingcrunch it would be true if the User were just a Credential, but in this case User and Consumer are the same person.

Maybe some VO's like BillingData and ShippingData. I would like to hear @pjedrzejewski and @umpirsky opinion.

[kingcrunch]

@marcospassos If you look at FOSUserBundle User is in fact the credentials. And on the other hand forcing, that Customer requires credentials by extending User is not what I intended with this ticket, rather I suggested to make them independent, so that it is possible, that not every customer must be a user too (which again may lead to legal problems).

Maybe some VO's like BillingData and ShippingData.

As far as I can see this is how vespolina solved it: The "customer" is represented by his addresses only, but it is not required, that he must be registered.

[jjanvier]

@kingcrunch the problem you raise in your last posts is only a "language" problem (at least I think, correct me if I'm wrong :) )

Currently in Sylius, users (or customers, this is exactly the same) has only one mandatory field : email. First name, last name and addresses are not mandatory to order something. Why ? Because there is no relation between the user's addresses and an order. When you create an order, this order has its own related addresses (shipping and billing), not the ones of the user / customer. Personal data of the customer (or profile, or user's data) are just meant to be shortcuts to order. In the future, (when this PR will be done), if a user selects one of his addresses to be shipped, we will in reality clone his address and link it to the order.

[kingcrunch]

@jjanvier So, is it possible to order something without getting registered as a User (or subclass, or whatever)?

[jjanvier]

@kingcrunch currently no because guest checkout is not yet implemented. But the separation between "FosUser" basic entity and "registered user" data is a first step to be able to provide this feature IMO. I just wanted to point out that "registered user" data are not linked to the order process, which is very important.

A few tickets have already been opened to ask about ordering without being registered. You should ask marcospassos or pjedrzejewski about that, but I don't think this is on top of the list ATM.

[jjanvier]

ping @pjedrzejewski @umpirsky for the name of the entity (I'd like to do this first before moving forward on the account section)

[jjanvier]

reping @pjedrzejewski @umpirsky