Как постараться не иметь очень большие объекты с Доменным Управляемым Дизайном

Я столкнулся с той же проблемой и обнаружил, что использование дочерних объектов «менеджер» было лучшим решением в нашем случае.

Например, в вашем случае вы могли бы иметь:

User u = ...;
OrderHistoryManager histMan = user.getOrderHistoryManager();

Тогда вы можете использовать histMan для чего угодно. Очевидно, вы подумали об этом, но я не знаю, почему вы хотите избежать этого. Это разделяет проблемы, когда у вас есть объекты, которые, кажется, делают слишком много.

Думайте об этом так. Если у вас был объект «Человек», и вы должны были реализовать метод chew(). Вы бы поместили его в объект Human или дочерний объект Mouth.

Хотя у настоящих людей много обязанностей, вы направляетесь к анти-шаблону объекта Бога .

Как уже намекали другие, вы должны выделить эти обязанности в отдельные Репозитории и / или Доменные службы . Например:

SecurityService.Authenticate(credentials, customer)
OrderRepository.GetOrderHistoryFor(Customer)
RefundsService.StartRefundProcess(order)

Будьте конкретны с соглашениями об именах (т. Е. Используйте OrderRepository или OrderService вместо OrderManager )

Вы столкнулись с этой проблемой из-за удобства . то есть удобно рассматривать WebsiteUser как совокупный корень и получать доступ ко всему через него.

Если вы сделаете больший акцент на ясности вместо удобства , это должно помочь разделить эти проблемы. К сожалению, это означает, что члены команды должны знать о новых Сервисах.

Еще один способ думать об этом: точно так же, как сущности не должны выполнять свою собственную постоянство (именно поэтому мы используем репозитории ), ваши WebsiteUser не должен обрабатывать возврат / сегментацию и т. д.

Надеюсь, это поможет!

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

Проблемы, которые вы видите, вызваны не дизайном, ориентированным на домен, а, скорее, отсутствием разделения проблем. Доменно-ориентированный дизайн - это не просто объединение данных и поведения.

Первое, что я бы порекомендовал, это потратить день или около того на чтение Domain Driven Design Quickly , доступного для бесплатной загрузки с Info-Q. Это предоставит обзор различных типов объектов домена: сущностей, объектов значений, служб, репозиториев и фабрик.

Второе, что я бы порекомендовал, - это прочитать Принцип единой ответственности .

Третье, что я бы порекомендовал, - это начать с погружением в Разработка через тестирование . Хотя обучение дизайну путем написания тестов не обязательно сделает ваш дизайн отличным, они, как правило, направляют вас к слабосвязанным проектам и выявляют проблемы дизайна раньше.

В приведенном вами примере у WebsiteUser определенно слишком много обязанностей. Фактически, вам может вообще не понадобиться WebsiteUser , поскольку пользователи обычно представлены ISecurityPrincipal .

Сложно сказать, как именно вам следует подходить к дизайну, учитывая отсутствие бизнес-контекста, но сначала я бы порекомендовал провести мозговой штурм, создав несколько учетных карточек, представляющих каждое из основных существительных, которые есть в вашей системе ( например, Клиент, Заказ, Квитанция, Продукт и т. д.).Напишите имена классов кандидатов вверху, какие обязанности, по вашему мнению, присущи классу слева, а классы, с которыми он будет сотрудничать, справа. Если какое-то поведение не соответствует ни одному из объектов, это, вероятно, хороший кандидат на услугу (например, AuthenticationService). Разложите карточки на столе со своими коллегами и обсудите. Однако не придавайте этому слишком большого значения, так как это на самом деле задумано только как мозговой штурм по дизайну. Иногда это может быть немного проще, чем использовать доску, потому что вы можете перемещать предметы.

В долгосрочной перспективе вам действительно стоит взять книгу Эрика Эванса Domain Driven Design . Это большое чтение, но оно того стоит. Я также рекомендую вам выбрать Гибкая разработка программного обеспечения, принципы, шаблоны и практики или Гибкие принципы, шаблоны и практики в C # в зависимости от ваших языковых предпочтений.

Возможно, вы захотите рассмотреть возможность инверсии некоторых вещей. Например, клиенту не обязательно иметь свойство Order (или историю заказов) - вы можете не включать их в класс Customer. Поэтому вместо

public void doSomethingWithOrders(Customer customer, Calendar from, Calendar to) {
    List = customer.getOrders(from, to);
    for (Order order : orders) {
        order.doSomething();
    }
}

вы можете сделать:

public void doSomethingWithOrders(Customer customer, Calendar from, Calendar to) {
    List = orderService.getOrders(customer, from, to);
    for (Order order : orders) {
        order.doSomething();
    }
}

Это более слабая связь, но все же вы можете получить все заказы, принадлежащие заказчику. Я уверен, что есть более умные люди, чем я, которые имеют правильные имена и ссылки, относящиеся к вышесказанному.

Очень простое практическое правило, которому следует следовать: «большинство методов в вашем классе ДОЛЖНЫ использовать большинство переменных экземпляра в вашем классе» - если вы будете следовать этому правилу, классы будут автоматически нужного размера.