Сколько логики должно быть в ваших объектах модели предметной области

Question

Только что закончил читать эта почта Грега Янга, где он говорит о том, что Microsoft рекомендует шаблоны с глупыми объектами передачи данных.Он намекнул, что в сообществе Java дела идут в другом направлении.

Мой вопрос: сколько логики должно быть в ваших объектах сущности?Наша философия, в которой я работаю (магазин C#), заключается в том, что если вы не можете сериализовать это, не помещайте это в сущность.

Answer 1

Мэтт,

Я бы сказал, что ваш магазин пишет процедурный код.Я хочу прояснить, что нет ничего плохого в том, что многие большие системы (в том числе многие, над которыми я работал) написаны с использованием процедурного кода.Для этого есть время и место.

Теперь процедурному коду нет места в модели предметной области.Если вы хотите использовать более процедурный стиль, это нормально, но используйте его с чем-то вроде модуля таблицы или шаблона активной записи.Я считаю не отсутствие объектно-ориентированного подхода столь разрушительным в руководстве, а использование модели предметной области с процедурной логикой.

Это приводит к тому, что приходится тратить большое количество ресурсов на создание уровня предметной области (несогласование импедансов, время мыслительного процесса для построения агрегатов, изоляция, повсеместный язык и т. д.), не получая при этом каких-либо преимуществ, которые в противном случае обеспечивал бы уровень предметной области (как правило, удобство обслуживания).Другими словами, хотя вы можете вполне удовлетворить свои функциональные требования, в конечном итоге вы потратите большую часть своего бюджета практически без возврата.

Теперь, возвращаясь к тому, что «является поведением», я хотел бы сосредоточиться на вопросе с точки зрения объектно-ориентированного, а не с точки зрения «предметно-ориентированного проектирования».Объект обычно инкапсулирует некоторое состояние и обычно демонстрирует некоторые варианты поведения.

быстрое повторение:инкапсулировать состояние, раскрывать поведение

Итак, какое поведение должен иметь объект?Проще говоря, это должно быть поведение, воздействующее на состояние, которое оно инкапсулирует.В идеальном поведенческом объектно-ориентированном мире состояние никогда не будет раскрываться только из поведения объекта.Тактически впишите в код, если мы начнем видеть такой код:

Customer c = GetCustomerFromRepository();
c.Status = CustomerStatuses.Deleted;
c.LastUpdated = DateTime.Now;
c.UpdatedBy = GetCurrentUser();
CustomerRepository.Save(c);

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

Инкапсулируйте информацию о клиенте и раскрывайте его поведение.

Таким образом, мы видим, что было бы лучше иметь метод Customer.Delete().(да, это плохой пример, я знаю...)

Теперь мы также доберемся до этого, используя TDD.Нам гораздо проще иметь дело в тестах со швом, который обеспечивает поведение, чем со швами, где выставлено все состояние.Причина этого в том, что мне не нужно дублировать логику в моих тестах.Клиентский код не Забота как работает удаление...его заботит только то, что клиент разоблачает свое поведение.Таким образом, в наших тестах вместо того, чтобы утверждать, что c.State == CustomerStates.Deleted и c.UpdatedBy==GetCurrentUser() и т. д. и т. д., мы просто утверждаем, что метод удаления был вызван на шве клиента с использованием макета.

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

Это поможет немного прояснить ситуацию?

Грег

Answer 2

Если вы называете их своим & объектом доменной модели " тогда я предполагаю, что вы ссылаетесь на модель доменной модели Фаулера. http://martinfowler.com/eaaCatalog/domainModel.html

Учитывая это предположение, тогда ответ на ваш вопрос " вся бизнес-логика " так как это по сути определение шаблона.

К сожалению, термин " модель домена " Похоже, что недавно он был смягчен для обозначения объектной модели ваших данных без какого-либо поведения.

Если вы еще этого не сделали, я бы посоветовал вам прочитать PoEAA и решить, где, по вашему мнению, логика предметной области относится к вашей ситуации. Если вы решите выбрать модель предметной области, я бы посоветовал вам прочитать книгу DDD Эвана и узнать о различиях между сущностями, объектами стоимости и услугами.

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

Answer 3

В последнее время я играю над идеей создания моделей предметной области, которые имеют структуру и только те поведения, которые являются универсальными для этой модели (т. е. поведения, которые могут использоваться в нескольких ограниченных контекстах) с методами расширения для поведения, характерного для ограниченный контекст. Это поддерживает модели предметной области близкими к DTO (для тех, кому это нравится) и ограничивает использование этой модели предметной области только допустимым поведением в ограниченном контексте. Так что это может быть вариантом для ответа посреди дороги. :)

Answer 4

Главный вопрос в том, как определить логику.Приведу несколько примеров:

1. Я бы не стал классифицировать функцию getFullName() в сущности Person, которая просто объединяет некоторые строки, как логику.
2. Расчет стоимости позиции заказа, скорее всего, можно назвать логикой.
3. Я бы определенно сказал, что выполнение некоторых транзакций бронирования — это логично.

Пункт 1 и, возможно, 2 ушли бы для меня в сущность.Пункт 3 нет.Итак, я определяю логику как:

• любая операция, которая выполняет какие-либо действия, связанные с сохранением (чтение/запись)
• любая операция, которая включает в себя любую другую (не связанную напрямую, напримермастер-деталь) сущность

ИМО, ни одна из этих операций не принадлежит сущностям.

Теперь, почему/когда я бы не поместил в сущность также операции типа точки 1 и 2?Это довольно редкая ситуация, но я бы не стал этого делать, поскольку данные, хранящиеся в сущности, необходимо каким-то образом интерпретировать, прежде чем они смогут быть использованы приложением (например,если в зависимости от текущего пользователя содержимое поля X имеет другое значение), это означает, что сами данные объекта содержат некоторую логику.

Answer 5

Насколько я понимаю, вся бизнес-логика, связанная с сущностью, должна входить в эту сущность. Это состоит из любой логики, которая определяет поведение или внутреннюю структуру объекта на основе бизнес-правил системы. Это не должно включать логику представления или логику персистентности (очевидное исключение - шаблон проектирования Active Record), но должно включать такие вещи, как проверка данных, взаимосвязи сущностей, конечные автоматы и другие вещи, которые определяют поведение сущности в терминах реальной мир, который он пытается смоделировать.

Я пытаюсь взглянуть на это, пытаясь сделать свои модели максимально возможными. Всегда пытайтесь думать о том, как будет использоваться модель, если она будет перенесена в другую систему, где клиентский код (или код, использующий объект) может отличаться. Если функциональность не является частью сущности, будет ли она вести себя так же, следуя тем же бизнес-правилам? Если ответ отрицательный, то функциональность должна идти в сущности.