Каким образом лучше организовать связь между несколькими Entity, хранилищами и Domain Model? Здравствуйте.
В процессе реализации DDD застопорился на следующем:
Приложение хранит часть данных в БД, часть данных реализует через API к удаленному серверу. Соответственно было принято решение создать сущности на те данными, которые соотносятся с таблицами в БД - это для маппинга ORM, а другие соотнести с данными, необходимыми для работы с API . Полученные сущности по типу решено объединить в соответствующие Domain Model-s, которые бы отвечали поставленным бизнес требованиям.
Т.е. для примера:class PostEntity{
private $id;
private $externalId;
private $userId;
private $date;
}
class ExternalPostEntity{
private $id;
private $postCode;
private $author;
private $title;
private $description;
}
class PostModel{
private /*PostID*/ $postId;
private /*User*/ $user;
private /*Date*/ $date;
private $title;
private $description;
private $code;
}
Для работы с сохранением данным, создается репозиторий, внутри которого происходит обработка данных для БД через маппинг ORM и так же обработка и маппинг чепрез запросы к API . При вызове методов find*() собирается DomainModel соответственно.
Вопрос в том, насколько объективна такая реализация, или поискать другие варианты ?
Каким образом лучше организовать связь между несколькими Entity, хранилищами и Domain Model? Здравствуйте.
В процессе реализации DDD застопорился на следующем:
Приложение хранит часть данных в БД, часть данных реализует через API к удаленному серверу. Соответственно было принято решение создать сущности на те данными, которые соотносятся с таблицами в БД - это для маппинга ORM, а другие соотнести с данными, необходимыми для работы с API . Полученные сущности по типу решено объединить в соответствующие Domain Model-s, которые бы отвечали поставленным бизнес требованиям.
Т.е. для примера:class PostEntity{
private $id;
private $externalId;
private $userId;
private $date;
}
class ExternalPostEntity{
private $id;
private $postCode;
private $author;
private $title;
private $description;
}
class PostModel{
private /*PostID*/ $postId;
private /*User*/ $user;
private /*Date*/ $date;
private $title;
private $description;
private $code;
}
Для работы с сохранением данным, создается репозиторий, внутри которого происходит обработка данных для БД через маппинг ORM и так же обработка и маппинг чепрез запросы к API . При вызове методов find*() собирается DomainModel соответственно.
Вопрос в том, насколько объективна такая реализация, или поискать другие варианты ?
В процессе реализации DDD застопорился на следующем:
Приложение хранит часть данных в БД, часть данных реализует через API к удаленному серверу. Соответственно было принято решение создать сущности на те данными, которые соотносятся с таблицами в БД - это для маппинга ORM, а другие соотнести с данными, необходимыми для работы с API . Полученные сущности по типу решено объединить в соответствующие Domain Model-s, которые бы отвечали поставленным бизнес требованиям.
Т.е. для примера:class PostEntity{
private $id;
private $externalId;
private $userId;
private $date;
}
class ExternalPostEntity{
private $id;
private $postCode;
private $author;
private $title;
private $description;
}
class PostModel{
private /*PostID*/ $postId;
private /*User*/ $user;
private /*Date*/ $date;
private $title;
private $description;
private $code;
}
Для работы с сохранением данным, создается репозиторий, внутри которого происходит обработка данных для БД через маппинг ORM и так же обработка и маппинг чепрез запросы к API . При вызове методов find*() собирается DomainModel соответственно.
Вопрос в том, насколько объективна такая реализация, или поискать другие варианты ?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Подход, который вы описали, в целом, является допустимым и может быть эффективным в случае, когда у вас есть разные источники данных (API и БД), и вы хотите объединить эти данные в одном месте для работы с бизнес-логикой.
Однако есть несколько моментов, которые стоит учесть:
Поддерживаемость: убедитесь, что ваш код легко поддерживать и расширять в будущем. Помните, что DDD способствует упрощению работы с сложной бизнес-логикой, поэтому старайтесь сохранить чистоту доменной модели и разделение ответственностей.Производительность: обратите внимание на эффективность обращения к разным источникам данных. В случае, если у вас большой объем данных, может быть полезно оптимизировать процессы загрузки данных из разных источников.Тестируемость: убедитесь, что ваш код легко тестируется, включая модульные, интеграционные и функциональные тесты.Если вам кажется, что текущая реализация не соответствует этим требованиям, то стоит рассмотреть другие варианты. Например, вы можете использовать сервисы, которые будут отвечать за работу с разными источниками данных и конвертирование их в доменные модели. Также можно рассмотреть использование шаблонов проектирования, таких как Repository или Data Mapper, для улучшения организации кода.
В любом случае, важно принимать решения, основываясь на конкретных нуждах вашего проекта и обсуждать их с командой, чтобы найти оптимальное решение.