Итак, я начал свою вторую работу разработчика, проработав 10 лет в своей первой компании и не очень чувствуя, что заслужил звание старшего разработчика. Это была разработка на Java, но мы работали с анемичной моделью предметной области, и приложение, на мой взгляд, представляло собой огромный беспорядок, который трудно тестировать. К сожалению, кодовая база, с которой я сейчас работаю, точно такая же, и недавно у меня было другое интервью, где интервьюер описал свою модель Hibernate как легкую и содержащую только сеттеры и геттеры. Так что, похоже, это довольно распространено в отрасли.
Существует множество статей, описывающих анемичную модель предметной области как антишаблон, а также несколько статей, в которых она описывается как идеально подходящая для простых систем. Но я не видел примеров получения максимальной отдачи от работы с крупной корпоративной системой с ADM.
Кто-нибудь имел опыт с этим? Существуют ли какие-либо передовые методы создания слабосвязанной системы, содержащей читаемые и действительно ценные модульные тесты? Я действительно хочу гордиться своей работой, но теряю надежду.
Редактировать: Разработчикам, которые выступают за то, чтобы бизнес-логика содержалась в сервисах:
как вы ограничиваете зависимости от других служб внутри каждой службы? то есть OrderCancelService нуждается в CustomerAccountService и PaymentService и RefundCalculatorService и RewardsAdjustmentService и т. д. Это приводит к нескольким фиктивным объектам в тестах, что делает тесты слишком привязанными к реализации
как вы ограничиваете количество параметров в методе каждой службы? Поскольку все должно передаваться, а объекты не работают со своими собственными данными, это, по-видимому, приводит к очень большим и запутанным сигнатурам методов.
Применяете ли вы принцип «скажи, не спрашивай» для обслуживания объектов? Я вижу много сервисов, которые возвращают значения, которые затем используются вызывающим сервисом для принятия решений в потоке выполнения.
