Size: a a a

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

2021 July 16

PD

Phil Delgyado in Архитектура ИТ-решений
Вообще не понял вопроса.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Коллеги, мне кажется мы опять углубимся не туда
источник

p

pragus in Архитектура ИТ-решений
Меня смутило разделение int/ext. У тебя был gw и потом появилась ещё 1 интеграция чуть с другим протоколом. Воткнули для неё адаптер, получилось [adapter] => [gw] => [system]

Короче, не связано это с ext/int.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ок, смотри, можно поменять названия того, что есть у меня:
frontend specific services (bff)
public api (api) - это вообще часто отдельный продукт
process services - это как раз про business scenarios
Разницу между business и entity у меня сейчас нет, это один вид сервисов, domain
Integration services (gateways)
AntiCorruptionLayer serivices (adapter)
Ну и utility = infra
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
хм. интересно, люди дающее слову "адаптер" значение "gw изнутри наружу", они вообще хоть раз в своей жизни видели, собственно, адаптер? )))
источник

PD

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

PD

Phil Delgyado in Архитектура ИТ-решений
Я видел много адаптеров, да )
И да, это про сервисы для "прогнуться под чужой изменяющийся мир".
Ну, например, как адаптеры для вилок для бытовой техники )
источник

p

pragus in Архитектура ИТ-решений
Примерно со всем: и с терминологией, и содержанием.
источник

PD

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Корелляция есть)
Кстати, теперь уже понятно, что Entity Service чаще Анти-паттерн, и уж точно Анти-паттерн в DDD
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, вот не уверен, кстати. У меня domain довольно "анемичные", там бизнес-логики минимум, в основном персистанс, почти entity. Но так удобнее.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
как раз плохой пример в плане направления - вообще-то, ток течёт не только из стены в прибор, а очень даже в обоих направлениях

Гораздо мнемоничнее было бы считать, что GW это про место на стыке сред, а адаптер это про преобразование из одного формата\протокола\типа в другой.
источник

p

pragus in Архитектура ИТ-решений
1. Не вижу никакой связи паттернов и доступности.
2. То что какой-то паттерн используют чаще всего для достижения цели N - это не значит что он для этого.

Классическое "каждая селёдка - рыба, но не каждая рыба - селёдка".
источник

p

pragus in Архитектура ИТ-решений
+
источник

PD

Phil Delgyado in Архитектура ИТ-решений
При чем тут ток? С точки зрения прибора у него ровно один исходящий интерфейс - вилка европейская.
Адаптер позволяет его использовать в других странах с другими розетками.
источник

p

pragus in Архитектура ИТ-решений
Крч, не надо путать частное и общее.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
да, и тогда никакого "изнутри вовне" нет в помине, что в общем-то и правильно
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
и интерфейс не исходящий ни разу
источник

p

pragus in Архитектура ИТ-решений
+
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Эээ, еще раз, это - внутренняя терминология, а не публичная. И, разумеется, имеет смысл для конкретного проекта с учетом его истории.
И тут да, подобные ACL-сервисы принято называть адаптерами (и это часто). И адаптеры - всегда про вызовы внешних систем, а не про "быть вызванными внешними системами".
источник