справочные данные в DDD - PullRequest
Новая
       6

справочные данные в DDD

0 голосов
/ 25 апреля 2018

В качестве продолжения моего предыдущего вопроса , когда я начинаю путешествие DDD, у меня есть некоторые справочные данные в контексте фактурирования для кодов элементов, который управляется в контексте конфигурации. Подмножество данных отражается от Конфигурации до Выставления счетов (Id, Name), и мне нужно загрузить эту информацию для проверки того, что Код товара существует, если кто-то создает Счет.

Должен ли я моделировать эти справочные данные кода товара в качестве совокупного корня в контексте фактурирования? Это кажется мне немного «излишним», поскольку вы никогда не обновите код товара в контексте фактурирования, но в большинстве указаний по DDD говорится, что из хранилищ должны загружаться только агрегаты.

Я думал об объявлении репозитория 'lookup', который загружает сущности (так как они имеют идентификатор, поэтому я бы не предположил, что это объект-значение), а не хранилище для набора эталонных данных. Это то, что было бы приемлемо?

1 Ответ

0 голосов
/ 25 апреля 2018

Я думал об объявлении репозитория 'lookup', который загружает сущности (так как они имеют идентификатор, поэтому я бы не предположил, что это объект-значение), а не хранилище для набора эталонных данных. Это то, что было бы приемлемо?

Это правильная идея, но написание, которое вы используете, не совсем подходит. Концепция, которую вы ищете, это служба домена , а не хранилище .

Мне нужно загрузить эту информацию для проверки того, что код товара существует, если кто-то создает Счет-фактуру.

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

// choose a spelling that is compatible with your naming conventions
// for domain services.
interface ItemCodes {
    boolean exists(ItemCode itemCode);
}

// In your domain model, the use looks like
class InvoiceModel {
    void createInvoice(..., ItemCodes itemCodes, ....) {
        //...

        if (! itemCodes.exist(code) ) {
            ...
        }
    }
}

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

Подробнее о доменных службах см. В главе 5 синей книги .

Я думал о создании службы инфраструктуры для проверки, но хотел посмотреть, является ли это приемлемым подходом. Было бы приемлемо иметь логику доступа к данным внутри этого класса обслуживания инфраструктуры, или у меня все еще должен быть дескриптор класса репозитория?

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

...