Структура решения DDD - PullRequest
Новая
       25

Структура решения DDD

0 голосов
/ 01 октября 2018

Я пытаюсь создать хорошую структуру решения для нового проекта DDD.Я создал «базовый» проект, в который я добавил Entities, ValueObjects и интерфейсы репозиториев, затем я добавил «Infrastructure» проект, который содержит реализацию предыдущего IRepository.

Теперь, так как мой db будет MongoDbМне нужно добавить атрибуты типа «[BsonDateTimeOptions]» в некоторых полях сущностей, для этого потребуется добавить ссылку на пакет драйвера MongoDb в основном проекте.

Поскольку основной проект не долженсодержит какую-либо ссылку на MongoDb, должна содержать только бизнес-логику, и она должна быть многократно использована в любом другом проекте (мобильный - Xamarin), какой должна быть лучшая практика в этой ситуации?

Что я могу подумать:

  • сущности не будут содержать никаких ссылок на MongoDb
  • . Создайте в инфраструктурных проектах модель для каждой сущности, то есть копию связанной сущности, но с атрибутами MongoDb.
  • создать слой (в хранилище?), Который может использоватьмодель для запроса в БД, затем преобразовать его в сущность и, таким образом, вернуть сущность, скрывая в хранилище объект модели.

У этого подхода есть проблема, что у меня будет копия сущностимодель, которая имеет только атрибуты MongoDb, и при добавлении некоторых полей в сущность мне придется изменить и модель.Это правильный подход?

Все началось с этой структуры решения.

Ответы [ 3 ]

0 голосов
/ 02 октября 2018

Примечание: я не использую C #, но это работает в PHP, и, возможно, это поможет вам

Они делают это так, чтобы создать объединенный корень, вложенные объекты и объекты Value.как простые объекты (данные + поведение, без какой-либо зависимости от инфраструктуры / технологии).Затем при сохранении / регидратации я использую рефлексию для хранения / загрузки агрегатов из репозитория.Репозиторий отображает любые известные доменные объекты на объекты инфраструктуры.Например, примитивные типы (string, bool, int, float, null) хранятся без каких-либо преобразований. Дата преобразуется в ISODate , Guid преобразуется в ObjectId и т. Д.

Это возможно из-за отражения и легко, потому чтоMongoDB хранит объекты в формате JSON, и существует небольшое (или отсутствует) несоответствие импеданса.

0 голосов
/ 02 октября 2018

Вместо использования атрибутов в ваших классах домена, напишите код конфигурации на уровне инфраструктуры.

Это, кажется, всегда вариант с MongoDB.NET, например, 

BsonClassMap.RegisterClassMap<MyClass>(cm => 
{
    cm.AutoMap();
    cm.MapMember(c => c.DateOfBirth).SetSerializer(new DateTimeSerializer(dateOnly: true));
}

вместо

[BsonDateTimeOptions(DateOnly = true)]
public DateTime DateOfBirth { get; set; }
0 голосов
/ 02 октября 2018

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

...