Организации DDD, использующие Услуги

Учитывая то, что мы видели о классах, я не думаю, что они на самом деле службы в синем цвете Книжный смысл , а калькуляторы я бы держал в Билете .

Ни FinancialCalculatorService , ни RateCalculationService не зависят от объектов домена - они оба работают с примитивными значениями. Приложениям не нужно беспокоиться о том, как рассчитать финансовую выгоду, которая может быть получена от билета, поэтому полезно инкапсулировать эту информацию внутри самого билета.

Если у них действительно нет зависимостей от сущностей предметной области, подумайте о них как о «автономных классах», а не о «сервисах» (опять же, в терминологии синей книги).Это, безусловно, подходит для Ticket , зависящих от объектов стратегии ( FinancialCalculator и RateCalculator ), которые сами по себе не имеют экзотических зависимостей и сами не изменяют состояние объектов домена.

Обновление для Edit 2 . Я думаю, что одним из преимуществ отдельных классов калькуляторов является то, что вы можете тестировать их независимо от Ticket . Строго говоря, билеты не несут ответственности за выполнение этих вычислений, они несут ответственность за правильные вызовы этих сотрудничающих классов. Поэтому я был бы склонен сделать их способными к инъекции / имитацией, как в вашем первоначальном примере.

Я бы сказал, что службы используют сущности, а не наоборот.

еще кое-что, не уверен в вашем домене, но вы уверены, что билет является сущностью, а не объектом значения?

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

Лично я не заставляю моих сущностей использовать сервисы, так как это создает массу работы вокруг вопроса «Как мне аккуратно добавить сервисы в мои сущности?» вопрос.

Мне кажется, что CalculateFinancialGains () - это скорее вызов уровня обслуживания. Это действительно приводит к сильной анемии у Ticket, но я предполагаю, что у него другое поведение? А если нет, то, вероятно, запах ...

Этот вопрос на самом деле является примером обсуждение, которое есть в книге «Чистый код» (стр 96-97). Основной вопрос заключается в том, следует ли использовать процедурный подход или объектно-ориентированный подход. Надеюсь, я не нарушаю, повторяя здесь пару частей, но вот то, что Боб Мартин указывает в качестве руководства:

Процедурный код (код, использующий структуры данных) упрощает добавление новых функций без изменения существующих структур данных. С другой стороны, объектно-ориентированный код упрощает добавление новых классов без изменения существующих функций.

Этот комплимент также верен:

Процедурный код затрудняет добавление новых структур данных, потому что все функции должны изменяться. ОО-код затрудняет добавление новых функций, потому что все классы должны измениться.

Насколько я понимаю, DDD «Тип значения» будет тем, что Боб Мартин называет структурой данных.

Надеюсь, это поможет, а не только усилит шум :)