214 похожих чатов

Здравствуйте, слышал мнение что entities из domain лучше дублировать в

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

Это излишество? И ничего плохого нет в том чтобы сущности импортировать из domain слоя?

6 ответов

10 просмотров

Я на той неделе читал вот такую статью: https://habr.com/ru/company/mobileup/blog/335382/ И вроде в целом понял, а теперь читаю ваш вопрос и понимаю, что или я всё-таки ничего не понял или вопрос неправильный😁

Entity в domain представляют собой объекты, которые будут использоваться непосредственно в приложении, entity в data будут представлять собой объекты, которые приходят из интернета к примеру, или их базы данных. Они могут отличаться. К примеру в data могут быть поля, которые не используется в приложении - зачем их тогда тащить в domain? К тому же если приложение использует несколько источников данных(internet, bd) то entity для них будут разные в data, но domain не должен об этом ничего знать.

Виталий-Анатольевич Автор вопроса
Viacheslav
Entity в domain представляют собой объекты, которы...

Спасибо, но я не говорил о том чтобы что-то тащить в domain. В том то и дело, у нас объекты могут быть одни и те же как в data так и в domain. Я ведь в domain в интерфейсе репозитория указываю что я возвращаю эти сущности в функциях? Так я хочу узнать, если я например продублирую их в data, это сведёт связность между data и domain до одного класса - repositoryImpl

Я так понимаю, больше речь про DTO\Модельки. А то за неверное использование Entity тут некоторые живьём сожрут. >Это излишество? Вся архитектура может быть излишеством. Не надо так категорично. Всегда стоит смотреть на ситуацию целиком. Где-то это необходимо, где-то действительно лишняя головная боль. Но чаще всего конкретно тут разделение сущностей — полезная практика, т.к. бэк, локальные базы данных — штуки довольно непредсказуемые. Если завтра изменится схема БД или ответ от сервера — то нужно будет править лишь изменённую модельку и маппинг. Ну и конечно, если мы говорим о разделении на слои, то domain не должен знать о какой-то внутренней кухне, а часто для работы с DTO нужны какие-то аннотации\имплементации. >И ничего плохого нет в том чтобы сущности импортировать из domain слоя? Ничего плохого нет, более того, в data-слое и так, и сяк имеется связь с domain. Они общаются через общие интерфейс и модельки.

Похожие вопросы

Обсуждают сегодня

Вопрос по диагностике ошибок (я знаю в чем, в данном конкретном примере, я знаю, как исправить, пример модельный, понятно, что в реальности бывает намного запутаннее). module...
ⰄⰎⰋⰐⰐⰑⰛⰤⰧⰧⰩⰄ ⰊⰑⰁⰓⰡⰛⰦⰕⰫ
10
Тут кста кто-нибудь NeoVim использует?
Simple Sorcerer
13
А чем вам питонисты не угодили?😂
.
79
Есть какой-нибудь для Delphi/FPC T*Compression(Decompression)Stream на базе LZ4/Zstd/любой другой быстрый(и хорошо сжимающий) алгоритм А ещё лучше в pure pascal А ещё лучше од...
notme
52
А дальше что?.. Записать в файл, потом в Код?.. И потом разбирать как-то?..
Хаскель Моисеевич Гопник
14
доброго времени. db, dw и прочие исполняются при трансляции или при выполнении программы?
lutayyy
10
Почему никто не подсказал, что можно объявить свои типы данных, в которых меньше полей, чем в отданном джейсоне, и добавлять их по необходимости?
Strange Rabbit
10
Хтось використовував Vapor на Windows?
Jaroshevskii
15
type TObj = object procedure Init; virtual; end; TObj1 = object(TObj) procedure Init; override; end; procedure TObj1.Init; begin inherited; end; procedur...
Alexander 👋
29
Всем привет, написал код ниже, но он выдает сегфолт, в чем причина? #include <stdio.h> #include <stdlib.h> #include <string.h> struct product { char *name; float price; };...
buzz базз
86
Карта сайта