анемичен модел на домейн и домейн услуги

Обикновено, когато не се използва анемичен модел, все пак ще имате нужди, които изискват специфични за домейн услуги. Това е така, защото неанемичните модели (или просто модели, ако желаете) трябва да съдържат код, който позволява да бъдат манипулирани, но трябва да се въздържат от вземане на зависимости от други модели, особено модели, които не са пряко свързани чрез връзка родител/дете .

Отделните домейн услуги ще ви позволят да поддържате това разделение и все още да предоставяте богата функционалност, тъй като те домейн услуги могат потенциално да бъдат запознати с по-голям изглед на целия модел на домейн.

Що се отнася до валидирането, не е необичайно тези модели да предоставят собствено валидиране, просто не забравяйте, че понякога валидното състояние на модел зависи от по-широк контекст, за който моделът може да не е запознат, така че външното валидиране вероятно все още ще съществува .

И накрая, гъвкавостта на модулното тестване ще зависи до голяма степен от вашето приложение и основната технология (като избор на език). Не съм виждал много случаи, в които всеки от двата подхода има достатъчно влияние върху тестването на единици сам по себе си.

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 елементи, които трябва да бъдат обединени (спестява разходи за доставка!)

Услугите за домейн обикновено съдържат функционалност на домейн, която естествено не се вписва в нито един от вашите обекти. Често това е функционалност, която се изисква от много други обекти на домейн, потенциално превръщайки услугата на домейн в голяма връзка, където се свързват много обекти.

Що се отнася до валидирането, то може да бъде на различни места в зависимост от това кога и какво искате да валидирате:

• Фабриките налагат инварианти при създаването на обект

• Агрегираните корени налагат инварианти, които засягат целия агрегат

• Базовото валидиране също често се извършва вътре в самите обекти

• Можете да имате персонализирано валидиране, което изисква данни, свързани с текущото състояние на приложението, като в този случай е по-вероятно валидирането да се извърши в слоя на приложението.