Как сделать лучшую модель анемичной области без другого выбора

Question

Итак, я начал свою вторую работу разработчика после того, как провел 10 лет в моей первой компании и не чувствовал, что получил звание старшего разработчика. Это была разработка Java, но мы работали с анемичной моделью предметной области, и приложение, на мой взгляд, было огромным трудным для тестирования беспорядком. К сожалению, кодовая база, с которой я сейчас работаю, точно такая же, и у меня недавно было еще одно интервью, где интервьюер описал свою модель Hibernate как легковесную и просто содержащую сеттер-геттеры. Похоже, что это довольно часто встречается в отрасли.

Существует множество статей, описывающих модель анемичной области как анти-паттерн, а также несколько статей, в которых она описана как идеально подходящая для простых систем. Но я не видел примеров того, как лучше всего работать с крупной корпоративной системой с помощью ADM.

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

Изменить: разработчикам, которые поддерживают бизнес-логику, содержащуюся в сервисах:

• как вы ограничиваете зависимости от других сервисов внутри каждого сервиса? то есть OrderCancelService нуждается в CustomerAccountService и PaymentService и RefundCalculatorService и RewardsAdjustmentService и т. д. Это приводит к тому, что в тестах несколько фиктивных объектов делают тесты слишком привязанными к реализации

• Как вы ограничиваете количество параметров в методе каждого сервиса? Поскольку все должно быть передано, а объекты не работают с собственными данными, это может привести к очень большим и запутанным сигнатурам методов.

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

Answer 1

Вы можете рассматривать свою модель персистентности, которую вы сейчас рассматриваете, как анемичную модель домена, как то, что она есть - модель персистентности для состояния вашей модели домена.

Если вы сделаете это, вы, вероятно, сможете создать реальную модель предметной области, в которой ее состояние будет храниться внутри объектов модели постоянства (шаблон состояний). Затем вы можете иметь свою логику внутри этой новой модели предметной области. Читая ваш комментарий выше, я бы сказал, что вы можете преобразовать ваши классы "менеджер / сервис" в конечные автоматы, вы можете называть их агрегатами, если они совпадают с границами транзакций, и их состояние в POJO сохраняется в Hibernate, как это делается сейчас.