Поведение объекта домена как

Question

Вот довольно тупой, но совершенно верный вопрос от новичка.Контекст: мой «объект домена» имеет имя (и некоторые другие атрибуты, но они не важны).Это имя генерируется в соответствии с некоторыми шаблонами, которые определены в базе данных.Теперь ... кто должен определять имя объекта домена?Если объект домена определяет свое собственное имя (обратите внимание, что это «имя» может быть основано на его собственном или каких-либо других атрибутах объекта) или служба должна определить имя в соответствии с шаблоном, а затем вызвать что-то вроде

domainObject.setName(theActualName)

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

Большое спасибо за ваши ответы.

Answer 1

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

Answer 2

Пара вопросов имеет отношение к этому:

1. Вам нужно какое-то управление именами? (Примером может служить каталог для поиска объекта по имени.) Если это так, рассмотрите возможность использования службы. (Альтернативой может быть организация каждого доменного объекта для регистрации самого себя после определения его имени.)
2. Являются ли объекты домена логически независимыми от базы данных после их создания и имен? Если это так, то было бы полезно сохранить их независимыми, поместив зависимость базы данных в службу.

Если доменные объекты все равно будут привязаны к базе данных, и если нет необходимости централизованно управлять именами, то я думаю, что наличие имен доменных объектов само по себе ведет к большей целостности объектов .

Answer 3

Думаю, вам стоит взглянуть на Принцип «Не спрашивай»

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

Просто будь проще.Я бы не стал вводить класс обслуживания, если бы мне это не нужно.В терминах DDD вы должны поместить логику, связанную с вашим доменом, в классы домена.