Дизайн, управляемый доменом, SOC и идентификация объекта

Question

Я пытался сосредоточиться на DDD и его связи с MVC, но у меня возникли проблемы с идентификацией сущности.

В частности, я пытаюсь поддерживать строгое разделение между моей презентацией, областью и моделями данных. Мое зависание заключается в том, как я сохраняю идентификацию сущности через эти границы. Чтобы уточнить, я использую отдельные классы для представления одной и той же сущности в разных контекстах - например, у меня есть класс домена ShipmentRequest, несколько классов представления ShipmentRequestView (в зависимости от свойств, требуемых для конкретного представления), и Таблица базы данных 'shipment_request' (моя модель данных).

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

Как мне сохранить это разделение и при этом отследить идентичность между этими слоями?

Answer 1

Без поля Id в вашей сущности вы не сможете сопоставить его со строкой базы данных. Поэтому это поле id, даже если оно не имеет ничего общего с вашими сущностями, должно проникнуть в вашу модель домена.

Мне кажется, что использование модели презентации чаще всего излишне, особенно если то, что вы пытаетесь достичь, это скрыть некоторые свойства.

Я думаю, что разделение интересов в основном обусловлено ограниченным контекстом. Например, ваша таблица Person, PersonView и Person, похоже, связана с контекстом обработки транзакций. В таком контексте я бы даже не использовал PersonView, и таблица person была бы абстрагирована.

С другой стороны, если вы находитесь в контексте отчетности, PersonView будет более полезным.

Я думаю, что контекст гораздо важнее, чем любая схема многоуровневой обработки.

Что касается отсутствия естественного ключа в вашей индивидуальной сущности, это может означать, что Персона на самом деле не является сущностью. Например, в любом реальном приложении всегда есть номер, связанный с человеком: у сотрудника есть номер сотрудника, у клиента номер счета и т. Д. Этот бизнес-идентификатор определенно является частью домена.

Answer 2

Запрос на отправку, безусловно, лучший пример!

Как пользователи найдут запрос на отправку? В зависимости от ответа вам может понадобиться идентификатор, который пользователи могут запомнить, например, 20091012-A.

Может ли идентификатор запроса на доставку измениться? Если нет, используйте ключ db для идентификации.

Вам нужно будет передавать запросы на отправку из одной системы в другую? Если да, не используйте ключ db для идентификации.

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

Answer 3

Я думаю, что наличие поля «ID» для сущностей - это уступка, которую многие (большинство?) Люди делают, и я не чувствую вины за это.

Как вы говорите, даже когда вы не имеете дело с базой данных, вам все равно нужно некоторое понятие идентичности. Вы можете попытаться придумать какую-то «естественную» идентичность для каждой сущности (поле, такое как имя, или комбинацию нескольких полей), но это не всегда возможно. Даже если это так, наличие поля идентификатора часто выступает в качестве удобного сокращения для того, чтобы сказать «объект, имя которого X, а дата рождения которого Y, а SSN - Z».

В конце концов, хотя и, возможно, менее «чисто», наличие поля идентификатора, вероятно, значительно упростит ситуацию.