DDD Бизнес-модель для отображения реляционной модели - PullRequest
2 голосов
/ 24 февраля 2010

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

Мне интересно, потому что изначально я думал, что он должен появиться из слоя хранилища, но давайте посмотрим на мои проблемы в этом случае. Хранилище члена должно возвращать бизнес-модель. Организация-член, имеющая в качестве собственности страну участника. Страна-член должна быть строкой (Германия, США, ..), и это будет означать, что хранилище участника получит выгоду от использования хранилища страны. Это право или хранилища должны работать отдельно. Или должен ли сервисный уровень создавать и возвращать бизнес-модель сущности-члена, используя различные репозитории? Если мое предположение о том, что бизнес-объекты должны выходить из уровня хранилища, должно ли происходить кэширование на уровне хранилища? Я имею в виду, что сопоставление между странами или более сложными отношениями должно выиграть от кэширования на уровне хранилища?

Спасибо

1 Ответ

2 голосов
/ 15 апреля 2011

Если у вас есть объекты, которые содержат только код и метку, которые часто называют «ссылочными значениями» или «номенклатурой», они должны обрабатываться иначе, чем другие объекты. Это не может быть решено с помощью доменного дизайна.

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

...