модель анемичного домена и доменные сервисы

Question

Если доменные сущности не являются анемичными, поэтому они встраивают поведение конкретного использования в себя, есть ли необходимость / точка для использования / создания определенных доменных служб?Как насчет проверки должна идти внутри сущности?

Какой способ более гибок для модульного тестирования?

Спасибо!

Answer 1

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

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

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

Answer 2

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

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

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

Проверка должна проходить внутри сущности.Например, предположим, у вас есть класс 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, которые должны быть объединены (это экономит расходы на доставку!)

Answer 3

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

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

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

• Агрегированные корни приводят в действие инварианты, относящиеся ко всей совокупности

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

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