Size: a a a

Архитектура ИТ-решений

2021 April 25

AV

Alexey Vetrov in Архитектура ИТ-решений
Есть заказ, в который мы можем добавлять позиции. У позиции могут быть дополнения. У дополнения как и у товара, есть своя цена (0 - тоже считаю ценой). Для каждого товара дополнения (!)кастомизируются. Дополнения для каждого товара ограничиваются минимальным и максимальным количеством. Отсюда получаем, что если минимальное количество больше нуля - оно обязательное.

У одного товара дополнение может быть с ограничением от 0 до 1, у другого - оно может быть с ограничением от 5 до 10, у третьего его может не быть вовсе.
Для примера у товара "телефон" - дополнение "симкарта" от 5 до 10, а у товара "планшет" от 0 до 1. У товара "ноутбук" его вовсе нет. Как пример дополнений: зарядные устройства, защитные стекла и тд.

Допустим, в заказе 2 позиции и каждая со своим дополнением. Первая - планшет Ipad Pro с дополнением "коробка от Ipad Pro". Вторая - телефон Galaxy J2 с дополнениями: "зарядное устройство Samsung" и "симкарта Tele2" в количестве 3 штук.

У меня есть сущности:
Item (id, name, availableItemAdditions) : Планшет, Ноутбук, Телефон
Addition (id, name) : Симкарта, коробка, стекло
ItemAddition (addition_id, max_amount, min_amount) : для телефона (симкарта 1-5, коробка 0-1, стекло 0-1), для планшета (симкарта 0-3, коробка 0-1), для ноутбука (коробка 0-1)


А теперь вопросы:
1) У меня сейчас товар сам знает о доступных ему дополнениях "ItemAddition". И при конструировании агрегата выбранного товара в заказе я на вход получаю Item и выбранные дополнения. Через Item я соответственно "валидирую" дополнение на минимально и максимальное количество. Если дополнения нет в доступных - я выбрасываю исключение.
2) Должен ли товар вообще знать о доступных к нему дополнениях. Или мне лучше создать условный конструктор, который на вход будет принимать товар, доступные ему дополнения и выбранные дополнения. Тогда вопрос как тут проверить то, что эти дополнения принадлежат именно этому товару? Допустим ситуация, где на вход ему поступит  (из примера выше) телефон №21 и доступные дополнения от телефона №22. Либо он сам должен внутри себя получать на вход выбранный товар и выбранные дополнениях. А внутри из условного репозитория получать по выбранному товару - доступные дополнения и уже по ним валидировать. Тогда как сам агрегат будет защищаться от инвариантов, если этим будет заниматься "Builder"?
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Не перегружайте "Item". Очень часто кажется, что это "более объектно" и "более DDD", но позже ведет к проблемам.
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Лучше, действительно, соберите логику компоновки в отдельном доменном сервисе, раз она нетривиальна. Агрегат заказа может у него спрашивать валидацию при добавлении строк и дополнений.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
По п.2:
- товар о допах знать не должен
- должен быть какой-то агрегат, товар с допами

Чтобы понять, что это за агрегат нужно лучше изучить домен. Уверен, у него уже есть название (вы как-то его называете  наверняка)
источник

AV

Alexey Vetrov in Архитектура ИТ-решений
В соседнем чате подсказали, что это всё-таки сущность в виде pivot связи с доп полями
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Почему?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Вы агрегируете товар и допы. Агрегируете в агрегате, не в сущности. Нет?
источник

AV

Alexey Vetrov in Архитектура ИТ-решений
Все верно. Сейчас думаю сделать отдельный агрегат, который будет собираться в билдере условном. Ему говорить какие допы доступны в товаре. И говорить ему собрать товар с такими и такими допами. Если что не так - кидай ошибку
источник
2021 April 26

AZ

Alexander Zaitsev in Архитектура ИТ-решений
есть двунаправленное общение клиент-сервер поверх одного двунаправленного канала (предположим вебсокеты). Клиент и сервер обмениваются между собой разного рода событиями. Хочу использовать Flatbuffers в качестве протокола общения.

Но так как события гоняются по одному каналу, то надо к событию как-то привязать схему, чтобы понять, как его парсить вообще на принимающей стороне.

Есть какой-то более адекватный способ, чем создавать вложенные FlatBuffers table? Сверху будет таблица с полем для схемы (имени схемы должно быть достаточно), а внутри уже поле Payload, которое содержит внутри событие, соответствующее этой схеме
источник

AZ

Alexander Zaitsev in Архитектура ИТ-решений
если кому интересно, то тут пару вариантов рассматривают: https://habr.com/ru/post/529846/
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А почему именно flatbuffers? И какой стек на обеих сторонах?
источник

AZ

Alexander Zaitsev in Архитектура ИТ-решений
flatbuffer потому что: бинарный и не имеет лишнего оверхеда по сравнению с протобуфом на сериализацию\десериализацию. Стек: на клиенте - C#, на сервере - Rust

Но я пока что играюсь больше, так что можно и поменять flatbuffers на что-нибудь другое бинарное
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, бинарных эффективных протоколов довольно много, тот же BSON, CBOR etc
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Т.е. насколько ли важна производительность flatbuffer, что можно жертвовать удобством разработки?
источник

AZ

Alexander Zaitsev in Архитектура ИТ-решений
хорошо. а как в них (BSON, CBOR) решается вопрос с передачей информации о схеме?
источник

AZ

Alexander Zaitsev in Архитектура ИТ-решений
ну из того, что я сейчас по PoC вижу - я в удобстве не теряю ни разу. Меня интересует только вопрос со схемой
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А в чем смысл передачи схемы вместе с данными?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Обычно передают просто какой-то код, по которому определяется как десериализовывать - класс+версия или что-то еще
источник

AZ

Alexander Zaitsev in Архитектура ИТ-решений
не, я хотел не саму схему передавать, а нечто, что идентифицирует схему. чтобы принимающая сторона по этому коду могла понять, как десериализовать
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну так добавь свои данные какие-нибудь )
Имя класса+версия или что-нибудь еще
источник