анемичная модель предметной области и доменные службы

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

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

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

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

Domain Services необходимы, когда у вас есть модель предметной области, потому что есть функции, которые не являются частью ваших сущностей.

Подумайте, например, о Repository или Factory. Интерфейс для Repository, вероятно, будет в вашем Domain Layer, но реализация в вашем Infrastructure Layer. С Factory и реализация, и интерфейс будут в вашем Domain Layer.

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

Проверка должна происходить внутри Entity. Например, предположим, что у вас есть класс Money.

public class Money
{
    public Money(string currency, int amount)
    {
        Currency = currency;
        Amount = amount;
    }

    public int Amount { get; set; }

    public string Currency { get; set; }
}

Если классу Money не разрешено иметь отрицательную сумму, где бы вы это подтвердили?

Лучшее место для этого - внутри класса. Сущность несет ответственность за свое состояние. В классе Money это легко увидеть, но, например, с классом Order с OrderLines Order отвечает за проверку наличия дубликатов OrderLine элементов, которые следует объединить (экономия затрат на доставку!)

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

Что касается проверки, она может быть в разных местах в зависимости от того, когда и что вы хотите проверить:

• Фабрики применяют инварианты при создании объекта

• Совокупные корни обеспечивают соблюдение инвариантов, которые касаются всего агрегата.

• Базовая проверка также часто выполняется внутри самих сущностей.

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