Гексагональная архитектура и Domain Driven Design на примере Front-end приложения

[JordanCpp]

Честно очень интересно, не чёт замороченно.) Идеи здравые, борьба со сложностью, со связанностю кода. Но когнитивная нагрузка от Овер абстракций над абстракциями, абстрагирующие нижележащие абстракции, возрастает.

[Libriant]

Да есть сложности с пониманием, сам долгое время думал что все это избыточно) время разработки увеличивается, разработчики адаптируются 1-2 недели. По итогу мы имеем независимость от бизнес логики или бекенда в нашем случае, тоесть до создания сущиностей на том же бекенде, можно оперировать замотанными данными, так как у нас свои независимые сущьности, подгонять данные из вне под себя через dto в адаптерах. Менять бекенд если захотим. Также приложению не придётся страдать в будущем, от внешних изменений, мы просто переписываем или заменяем первичный адаптер.

[derwin]

я тоже был адептом ддд, пока не попал на проект с ддд.

Вместо 4х if-ок мне нужно было создать 4 dto, 4 enum, 3 handler-а и всё это упаковать в фабрику. Пока читаешь (чужой) код - хочется плакать кровью.

[dopusteam]

Первичные  порты — это запросы поступающие в приложение http, api, подключение к бд.

А как подключение к БД является входящим для приложения? Выглядит как вторичный порт (согласно статье, они используются ядром приложения для доступа к внешним службам)

Вторичные порты используются ядром приложения для доступа к внешним службам.

адаптеры, которые устанавливают связь с внешним миром (api), реализуют первичный порт

Как это соотносится?

Вторичные порты используются ядром приложения для доступа к внешним службам

К примеру, адаптеры, взаимодействующие с веб-браузером реализуют вторичный порт

Получается, что наше приложение стучится в браузер?

INFRASTRUCTURE - это бизнес-логика

Вот эта штука меня смущает немного. Почему инфраструктура - это бизнес логика?

[Libriant]

Как это соотносится?

"Вторичные порты используются ядром приложения для доступа к внешним службам." - тут имеется в виду (внешние службы) тоесть - браузером апи, пользовательские действия (изменение состояния приложения), возможно стоит перефразировать, изменить формулировку для большей понятности?

может так:

Вторичные порты используются ядром приложения для доступа к внешним службам браузера, а также пользовательским действиям взаимодействующим с состоянием приложения.

А как подключение к БД является входящим для приложения?

в данном случае это получение данных из мне, поэтому первичный порт

Получается, что наше приложение стучится в браузер?

вызывает внешние службы, браузерное апи

[Libriant]

Вот эта штука меня смущает немного. Почему инфраструктура - это бизнес логика?

Наверное стоит исправить, согласен думаю - "Внешние системы"

[Bone]

ProductList врядли является Entity. Судя по тому, что у него нет id, это ValueObject.

[Libriant]

разве по определению entity должен иметь id? ProductList может иметь собственные методы, гетеры и сеттеры, любые другие поля, помимо массива продуктов.

[Bone]

Вообще, да. Можно сказать, что entity - это уникальная сущность с id, а value object - это нечто общее. При этом они могут иметь какие угодно методы и поля. Классический пример банковский счет, допустим такого вида

interface BankAccount {
  id: number
  money: Money
}

Это entity. Они сравниваются по id. Если разные id, то это разные entity даже, если у них совпадают все другие поля.

interface Money {
  amount: number
  currency: "RUB"|"USD"
}

Money - это value object. У него нет своей собственной идентичности. 500 долларов равны любым другим 500 долларам. Но банковский счет с 500 долларами не равен любому другому банковскому счету с 500 долларами.

[Libriant]

Получается если в ProductList добавить Id он станет сущностью, а без I’d он value object) Можно его конечно и добавить, если на проекте понадобиться хранить одновременно несколько ProductList, в данном случае в этом нет нужды.