Допустим у нас есть некая сложная сущность с большим набором связанных друг с другом свойств. Восстановление сущности - затратная операция. Сущность используется в большом количестве форм с всевозможными комбинациями свойств этой сущности. При этом сущность не подлежит кешированию. С точки зрения DDD допускается получение части свойств сущности, но в таком случае при попытки оптимизировать их частичное получение из репозитория энтропия комбинаций порождаемая формами приводит к энтропии в репозитории. Хочется что бы ни домен, ни рипозиторий не зависели от форм с разными комбинациями полей и при этом для форм собирались оптимальные сущности без лишних полей.
Попробую привести условный пример на сущности "Товар" У Товара есть свойства: Срок годности;Дата производства; Дата упаковки. И Производное свойство: Дата годности = дата производства + срок годности. Таким образом если запросить у сущности Товар дату годности и дату упаковки, то из репозитория потребуется получить 3 свойства: Срок годности, дату производства и дату упаковки. И комбинаций такого плана может быть очень много. Как правильно выходить из данной ситуации не нарушая DDD?
На пример когда много всяких выборок из базы с разными комбинациями join'ов. Если протаскивать их через доменый слой, то это может захламить домен кодом, который фактически не содержит бизнес логики.
Вы хорошо продумали стайлгайд доки, но по ощущениям у вас есть диспропорция между блоками: меню | контент | оглавление. Меню и оглавление забрали на себя в сумме 50% полезной зоны страницы, оставив контенту остальные 50%, в следствии чего он сильно растягивается вниз. Это особенно заметно на страницах с большими таблицами, на пример "Ошибки при работе с карточками товаров" в таблице "Ошибки в характеристиках товара" (https://docs.ozon.ru/global/products/upload/moderation/errors-with-pdps/?country=CN&__rr=1#ошибки-в-характеристиках-товара). Очень мало количество символов помещается в строке ячейки, в следствии чего фразы и предложения растягиваются на несколько строк, хуже всего приходится маркированным спискам.
SSE на мой взгляд будет проще в реализации. Отправляя отдельными http запросами команды прочтения/удаления вы получите больше возможностей: - возможность предобработки запроса; - балансировка нагрузки; - доменная декомпозиция, т.е. за прочтение и удаление могут отвечать разные обособленные друг от друга сервисы; - прозрайный пайплайн логирования; - можно удобно собирать аналитику; - можно в полной мере задействовать всю силу HTTP кодов для обработки кейсов.
При выборе решения поверх websocket вы можете столкнуться с: - необходимостью реализации прикладного протокола общения между клиентом и сервером либо внедрением одного из websocket фреймворков на пример Socket.IO; - websocket могут блочить в общественных сетях.
Возможно да, но как быть если мы уже встали на рельсы DDD?
@olkuчто можете рекомендовать почитать на эту тему?
Попробую переформулировать вопрос.
Допустим у нас есть некая сложная сущность с большим набором связанных друг с другом свойств. Восстановление сущности - затратная операция. Сущность используется в большом количестве форм с всевозможными комбинациями свойств этой сущности. При этом сущность не подлежит кешированию. С точки зрения DDD допускается получение части свойств сущности, но в таком случае при попытки оптимизировать их частичное получение из репозитория энтропия комбинаций порождаемая формами приводит к энтропии в репозитории. Хочется что бы ни домен, ни рипозиторий не зависели от форм с разными комбинациями полей и при этом для форм собирались оптимальные сущности без лишних полей.
Попробую привести условный пример на сущности "Товар"
У Товара есть свойства: Срок годности; Дата производства; Дата упаковки.
И Производное свойство: Дата годности = дата производства + срок годности.
Таким образом если запросить у сущности Товар дату годности и дату упаковки, то из репозитория потребуется получить 3 свойства: Срок годности, дату производства и дату упаковки. И комбинаций такого плана может быть очень много.
Как правильно выходить из данной ситуации не нарушая DDD?
Вопрос был адресован @olku Имел в виду про профит отказа от Interface в пользу Interface.
Как боритесь с энтропией?
На пример когда много всяких выборок из базы с разными комбинациями join'ов. Если протаскивать их через доменый слой, то это может захламить домен кодом, который фактически не содержит бизнес логики.
Есть что почитать на эту тему? Не улавливаю профита от задумки.
Вы хорошо продумали стайлгайд доки, но по ощущениям у вас есть диспропорция между блоками: меню | контент | оглавление.
Меню и оглавление забрали на себя в сумме 50% полезной зоны страницы, оставив контенту остальные 50%, в следствии чего он сильно растягивается вниз. Это особенно заметно на страницах с большими таблицами, на пример "Ошибки при работе с карточками товаров" в таблице "Ошибки в характеристиках товара" (https://docs.ozon.ru/global/products/upload/moderation/errors-with-pdps/?country=CN&__rr=1#ошибки-в-характеристиках-товара). Очень мало количество символов помещается в строке ячейки, в следствии чего фразы и предложения растягиваются на несколько строк, хуже всего приходится маркированным спискам.
Самое главное - ссылку на вашу новую документацию приложить забыли ;)
https://docs.ozon.ru/styleguide/formatting/
SSE на мой взгляд будет проще в реализации. Отправляя отдельными http запросами команды прочтения/удаления вы получите больше возможностей:
- возможность предобработки запроса;
- балансировка нагрузки;
- доменная декомпозиция, т.е. за прочтение и удаление могут отвечать разные обособленные друг от друга сервисы;
- прозрайный пайплайн логирования;
- можно удобно собирать аналитику;
- можно в полной мере задействовать всю силу HTTP кодов для обработки кейсов.
При выборе решения поверх websocket вы можете столкнуться с:
- необходимостью реализации прикладного протокола общения между клиентом и сервером либо внедрением одного из websocket фреймворков на пример Socket.IO;
- websocket могут блочить в общественных сетях.