Блог

Хорошо, люди,

В последние пару дней я думал, как это правильно реализовать, и я хотел бы знать, каким будет ваш подход к реализации следующего сценария:

• Я создаю платформу электронной коммерции, и у нас есть много видов «сущностей». Сущности не обязательно являются пользователями, которые имеют учетные данные и могут входить в нашу платформу, и все должно быть достаточно отделено от всего остального.

• Сценарий реальной жизни: у нас есть клиенты, сотрудники и поставщики, все они могут быть или не быть пользователями, например, у них могут быть или не быть учетные данные для входа. Я могу прикрепить контакт (адресную информацию) к любой из этих моделей или счет-фактуру… Идея в том, что у нас могут быть клиенты, у которых на самом деле нет учетных данных, которым мы выставляем счета, или создаем заказ для пользователя, который фактически не входит в систему… То же самое касается выставления счетов, я хочу иметь возможность выставлять счета как клиенту, так и поставщику.

Проблема, с которой я сталкиваюсь, заключается в том, что эти 3 типа пользователей более или менее одинаковы, к ним могут быть прикреплены заказы / счета / контакты / что угодно, но они не обязательно являются пользователями. Фактически, учетные данные должны быть чем-то, что мы должны иметь возможность прикрепить к любой из этих моделей, если захотим, чтобы у поставщика был логин для доступа ко всему, что им нужно.

Как бы вы это спроектировали?

Я бы логически отделил пользователей от организаций, затем создал абстракции как для пользователей, так и для организаций, затем создал для них конкретные классы, которые состоят в любой комбинации, подходящей для каждого. На самом деле у вас нет трех типов пользователей, у вас есть два типа: сотрудники и представители внешних организаций. У этих внешних организаций может быть несколько авторизованных пользователей (или нет), и они также могут иметь отношения с вашими сотрудниками. Вы не указываете, представляет ли клиент одного человека или организацию, это влияет на то, как вы моделируете свой домен. Вот как я бы смоделировал это, предполагая, что клиент логически является организацией, а не отдельным человеком. Если Customer это человек, authorizedUsers он переместился бы в Supplier , и Customer у него было бы одно User свойство.

 abstract class TransactionalEntity
{
    String name;
    Set<Address> billingAddresses;
    Set<Address> shippingAddresses;
    Set<Invoice> invoices;
    Set<Order> Orders;
    Set<User> authorizedUsers;
}

abstract class User
{
    String firstName;
    String lastName;
    String email;
    String username;
    String password;
}

class Supplier extends TransactionalEntity
{
    Set<Product> suppliedProducts;
}

class Customer extends TransactionalEntity
{
    Employee salesRepresentative;
}

class Employee extends User
{
    String title;
    Double salary;
    Date startDate;
    Address homeAddress;
    Employee supervisor;
}