Методы для контакта с анемичной моделью предметной области

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

Interface IPurchase
      Purchase(Product);

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

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

Логика вида:
«Customer.PurchaseProduct (Продукт продукта, Платежный платеж)»,
«Customer.KillCustomer (Убийца людей, огнестрельное оружие)»
должен существовать прямо в доменном объекте «Клиент».

Логика типа:
"Customer.IsCustomerAlive ()"
«Customer.IsCustomerHappy ()»
должен перейти к спецификациям.

Логика вида:
"Customer.Create ()",
«Customer.Update ()»
очевидно, следует перейти в репозитории.

Логика типа:
«Customer.SerializeInXml ()»
«Customer.GetSerializedCustomerSizeInBytes ()»
должны идти в службы.

Сложные конструкторы должны идти на фабрики.

Вот как я это вижу. Я был бы рад, если бы кто-нибудь прокомментировал мое понимание подхода DDD.

Изменить:

Иногда - анемичной модели домена не следует избегать .

Отредактировал свой ответ, чтобы добавить, что DDD не Не о том, чтобы собирать и опускать узоры.
DDD - это то, как мы думаем.

One approach that you haven't mentioned is using AOP to handle your data access. An example of my recent use of this approach (though vastly simplified for posting purposes) was that I had an Account domain entity which had a debit method, encapsulating the business logic required in order to make a successful debit from the account.

N.B. All code is Java with AspectJ AOP notation...

public boolean debit(int amount) {
    if (balance - amount >= 0) {
        balance = balance - amount;
        return true;
    }
    return false;
}

With the appropriate repository injected into my aspect, I then used a pointcut to intercept calls to this method...

pointcut debit(Account account,int amount) :
    execution(boolean Account.debit(int)) &&
    args(amount) &&
    target(account);

...and applied some advice:

after(Account account, int amount) returning (boolean result)  : debit(account,amount) {
    if (result) getAccountRepository().debit(account, amount);
}

In my opinion this gives a nice separation of concerns, and allows your domain entities to focus entirely on the business logic of your application.