Управление доменом, SOC и идентификация объекта

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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