DDD - CreatedBy/CreatedOn в доменной модели?

Question

При написании заявки по стандарту для каждой таблицы в базе данных у меня есть следующие свойства: CreatedOn, CreatedBy, ModifiedOn, ModifiedBy, Archived.

Но, пытаясь следовать DDD, я задаюсь вопросом, действительно ли эти свойства являются частью домена и должны быть включены в объекты домена. Если бы я исключил эти свойства «метаданных» из домена, но все еще хотел их в своей базе данных, тогда мне нужно было бы реализовать какой-то слой DTO, если бы я собирался использовать ORM.

Таким образом, модель домена отображается в DTO, CreatedOn, ModifiedOn и т. Д. Задается, а затем помещается в базу данных.

Поэтому я полагаю, что мои вопросы:

1. ли я просто жить с этими свойствами, как часть моей модели домена?
2. Удалять ли я их, но у вас есть головная боль, связанная с необходимостью сопоставить DTO?
3. Есть ли альтернатива, которая могла бы решить обе проблемы, такие как реализация какой-либо формы журнала аудита?

Answer 1

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

Вы быстро перейдете к точке, где вам все равно нужно сопоставить между табличными объектами ORM и агрегатами вашего домена.

Принуждение аспектов, основанных на базе данных, в вашей модели домена противоречит DDD.

Так что да, я бы рекомендовал сопоставлять таблицы-объекты ORM (которые являются чистыми данными в любом случае) в ваших агрегатах. Здесь воспроизводится шаблон хранилища. Он будет предоставлять объекты домена путем преобразования базовых данных.

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

многоуровневая архитектура может выглядеть следующим образом:

---------------------------- 
| Domain      | (Aggregates) 
---------------------------- 

---------------------------- 
| Repositories    | (transforms table-objects into Aggregates) 
---------------------------- 

---------------------------- 
| OR-Mapper     | (loads records from DB into table-objects) 
---------------------------- 

---------------------------- 
| Database     | (this is where the data lives) 
---------------------------- 

Answer 2

Единственный способ узнать это - попросить вашего владельца продукта, если эти поля актуальны в вашей модели. И если они есть, какие меры они имеют отношение?

---

Если бы я был, чтобы исключить эти «метаданные» свойства из области, но по-прежнему хотел, чтобы они в моей базе данных, то я бы [.....]

Почему? Они не являются частью модели, которая означает, что они не являются частью какой-либо логики в вашем домене.

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

Если журнал аудита является требованием, то они должны быть частью модели.

Answer 3

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

Если ваш домен является областью определения подлинности и контроля доступа, тогда у вас будут имена пользователей и т. П. Для чего-либо, использующего Identity и Access BC, могут быть разные. Возможно, вам потребуется добавить некоторую пользовательскую информацию в свой домен в виде объекта значения.

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