Size: a a a

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

2021 July 16

PD

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

GK

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

MS

Maxim Smirnov in Архитектура ИТ-решений
Архитекторы не верят в глоссарий. Скорее в контексты. Все мы используем один и те же слова в разных смыслах. Так что собирать, скорее, надо список предметных областей
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
В разных ограниченных (лингвистических) контекстах смыслы часто отличаются
источник

GK

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Выглядит излишне упрощённо. При всём неподдельном уважении к автору
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Хм, да. У меня в докладе более внятная структура (хотя я уже ее пересматриваю..)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Книге сто лет в обед (2016)
Не в этом суть
Про таксономию забыли
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Вообще посмотреть бы на разные существующие таксономии было бы интересно.
У меня пока bff/api/business scenarios/domain/gateways/adapters/infra
Но может быть этого маловато...
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Сколько было холивара вокруг размера микросервисов) две пиццы, возможность переписать за один спринт, SRP и т.д. и т.п. Пико/Нано/Микро/Гига...

А на самом деле, нужны были практики проектирования приложений выровненных с бизнесом.
SOA на эти запросы (выравнивание с бизнесом, TTM и пр) не отвечала, границы сервисов в SOA технические (из-за фокуса на максимизацию reusability/composability)

При этом хипстеры решили, это моё сугубо личное мнение, что чем меньше сервис, тем наверно проще повысить TTM. Хотя TTM (любого маленького сервиса) сам по себе не имеет большой ценности. Нужно уметь вовремя "выкатывать" бизнес-ценность, нечто, что имеет бизнес-смысл (пользу для пользователей)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ну смотри
У тебя перечислены несколько паттернов (bff, gateway), и ряд концептов и срезов
источник

PD

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

PD

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

PD

Phil Delgyado in Архитектура ИТ-решений
Для меня типы сервисов должны определять:
какие сервисы могут вызывать и откуда могут быть вызваны
как кастомизируются
как обеспечивается безопасность
какие типы persistance требуются
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Фил, не прослеживается связь с бизнесом. Чисто техническое рассмотрение
источник

p

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

PD

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

PD

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

p

pragus in Архитектура ИТ-решений
> gateway - это для доступа в систему "из вне", adapter - для доступа из системы "во вне".

Что мешает быть адаптеру перед гейтвеем?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ну смотри, в таксономиях SOA, а их несколько, было примерно следующее:
- Process services
- Business services
- Entity services
- Utility services

Иными словами, должно быть нечто (сервисы), что предназначено изначально для поставки бизнес-ценности.
источник