Блог

Я пытаюсь применить некоторые шаблоны, подобные DDD, к коду, который я пишу, чтобы использовать его в качестве примера того, как писать хороший код. У нас уже есть куча классов, которые представляют объекты домена, но большинство из них «слишком много знают» и имеют как логику, методы получения / установки, так и доступ к данным (в виде нетипизированных наборов данных), разбросанных по ним.

Для этой части приложения мне нужно использовать тот же объект домена, но с небольшим подмножеством возвращаемых данных, что затрудняет использование объекта «fat» (например, предположим, что объект «fat» имеет 20 свойств и методов, и я обращаю внимание только на работу с 7 свойствамидля этой части). Приемлемо ли для меня создать объект в стиле lean DTO с тем же именем (конечно, в другом пространстве имен / пакете) только с теми свойствами, которые мне нужны? Кажется, я помню, что это была хорошая практика в мире DDD, но я не могу точно вспомнить (насколько я помню, что-то связанное с ограниченными контекстами?), И я бы не хотел загрязнять свой дизайн.

Я бы с осторожностью отнесся к тому, чего вы пытаетесь достичь. Чтобы ИТ действительно управлялся доменом, ваши объекты должны обладать богатой функциональностью, а не «анемичной» доменной моделью

Итак, если вы окажетесь в ситуации, когда вам «нужно использовать тот же объект домена, но с небольшим подмножеством свойств», что именно использует объект домена в этом сценарии.

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

Если это так, вы можете пересмотреть свой дизайн, чтобы убедиться, действительно ли он ориентирован на домен.