Size: a a a

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

2020 August 25

EI

Eugene Istomin in Архитектура ИТ-решений
Fagor
Кросс проверки, так же вопрос практик, по сути это уже уровень не архитектуры ландшавта, а соглашения и практики внутрии организации к командам разработки
Ну вот это и есть архитектура же. Если бы ты написал "проектирование" - то ок, но архитектура про "соглашения и практики внутри организации и ... + ..."
источник

I

Ivan in Архитектура ИТ-решений
Vitaly U
@emacsway
Нет же, вот вопрос, вы видимо не туда посмотрели
Перечитал. Вроде понял все правильно. Если за преобразование данных отвечает их конечный потребитель, то это - Anti-Corruption Layer (и Message Mapper). А если существует отдельный узел для преобразования данных и питания ими всех потребителей, то это - Published Language (и Message Translator).

Вопрос Anti-Corruption Layer vs Published Language хорошо описан в литературе по DDD. А вопрос Message Mapper vs Message Translator (при условии, что данные доставляются сообщениями, а не, например, File Transfer, Pub/Sub etc.) хорошо описан в EIP и в RMPwAM. Что-то добавить от себя здесь сложно.

Но я бы начал все-таки с причины появления этого вопроса. Когда сервисы дублируют данные, то это происходит обычно как Eventual Consistency реакция одного сервиса на изменения в другом сервисе с целью обеспечения автономности сервисов и владения данными. В вашем же случае я не совсем понимаю причины возникновения такой потребности, когда разные сервисы импортируют из внешнего источника одни и те же данные.
источник

F

Fagor in Архитектура ИТ-решений
Все практики и соглашения? Код стайл это архитектура или? Я думаю что регламенты такого низкого уровня не нужны, иначе архитектура утонет.
источник

F

Fagor in Архитектура ИТ-решений
Это примерно когда менеджер пытается контролировать часы в задачах. Ни к чему хорошему это не приводит.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Fagor
Все практики и соглашения? Код стайл это архитектура или? Я думаю что регламенты такого низкого уровня не нужны, иначе архитектура утонет.
Пока мы оставляем в умолчаниях домен архитектуры - всё плавает.
Есть оргдизайн, который является реализацией смысла "организационная архитектура" (Organizational architecture or organization design: the creation of roles, processes, and formal reporting relationships in an organization.).

Этот чат про "архитектуру ИТ-решений", с одной стороны. С другой - архитектура ИТ-решений не живёт в вакууме.

В основном, мы тут обсуждаем две темы:
1) "вариации проектирования решений для обеспечения операционной деятельности таких-то людей-отделов-служб-клиентов"
2) "как перейти из домена ИТ-архитектуры в домен архитектуры организации".
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Istomin
Пока мы оставляем в умолчаниях домен архитектуры - всё плавает.
Есть оргдизайн, который является реализацией смысла "организационная архитектура" (Organizational architecture or organization design: the creation of roles, processes, and formal reporting relationships in an organization.).

Этот чат про "архитектуру ИТ-решений", с одной стороны. С другой - архитектура ИТ-решений не живёт в вакууме.

В основном, мы тут обсуждаем две темы:
1) "вариации проектирования решений для обеспечения операционной деятельности таких-то людей-отделов-служб-клиентов"
2) "как перейти из домена ИТ-архитектуры в домен архитектуры организации".
Хорошим тоном является знать оба "домена" (очень спорный в этом контексте термин ...), и смотреть, кому и зачем нужны "твои блестящие идеи техреализации в проекте по перераспределению власти в департаменте"
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Fagor
Я про интеграцию. Взаимодействия в моей работе мало, почти нет. Между системами. А то что есть реализованно на приемлемом уровне
Почему взаимодействия нет? Это же ключевой вопрос.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
Почему взаимодействия нет? Это же ключевой вопрос.
Так точно )
источник

I

Ivan in Архитектура ИТ-решений
Ivan
Перечитал. Вроде понял все правильно. Если за преобразование данных отвечает их конечный потребитель, то это - Anti-Corruption Layer (и Message Mapper). А если существует отдельный узел для преобразования данных и питания ими всех потребителей, то это - Published Language (и Message Translator).

Вопрос Anti-Corruption Layer vs Published Language хорошо описан в литературе по DDD. А вопрос Message Mapper vs Message Translator (при условии, что данные доставляются сообщениями, а не, например, File Transfer, Pub/Sub etc.) хорошо описан в EIP и в RMPwAM. Что-то добавить от себя здесь сложно.

Но я бы начал все-таки с причины появления этого вопроса. Когда сервисы дублируют данные, то это происходит обычно как Eventual Consistency реакция одного сервиса на изменения в другом сервисе с целью обеспечения автономности сервисов и владения данными. В вашем же случае я не совсем понимаю причины возникновения такой потребности, когда разные сервисы импортируют из внешнего источника одни и те же данные.
На всякий случай, еще одна ссылка по теме: https://www.enterpriseintegrationpatterns.com/patterns/messaging/CanonicalDataModel.html

Но лучше смотреть в EIP, а не онлайн-каталог. В каталоге все слишком сухо и коротко.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Fagor
Так оно и есть, контракт это согласованность, уровень лжи контракта не важен. Если он согласован с двух сторон.
На самом деле, есть альтернатива.

Поставщик публикует контракт, а потребители адаптируются.

Это единственный жизнеспособный вариант, когда потребителей много и/или их состав меняется.

Главное - потребители должны знать об изменениях заранее и иметь время на адаптацию. Обратная совместимость как минимум двух последних мажорных версий контракта, это одно из необходимых условий.
источник

I

Ivan in Архитектура ИТ-решений
Eugene Istomin
Хорошим тоном является знать оба "домена" (очень спорный в этом контексте термин ...), и смотреть, кому и зачем нужны "твои блестящие идеи техреализации в проекте по перераспределению власти в департаменте"
Совершенно верно. Именно поэтому, в одном из моих первых ответов, был отсыл к каталогу способов взаимодействия Bounded Contexts. Я упомянул только два способа, но их существенно больше, и все зависит от домена.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ivan
На всякий случай, еще одна ссылка по теме: https://www.enterpriseintegrationpatterns.com/patterns/messaging/CanonicalDataModel.html

Но лучше смотреть в EIP, а не онлайн-каталог. В каталоге все слишком сухо и коротко.
Mediation Framework содержит реализации почти всего каталога EIP.

Конкретный EIP нужно выбирать исходя из деталей задачи.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
Хорошим тоном является знать оба "домена" (очень спорный в этом контексте термин ...), и смотреть, кому и зачем нужны "твои блестящие идеи техреализации в проекте по перераспределению власти в департаменте"
Именно. Иначе будет пробел в распределении обязанностей, то есть пробел в архитектурной работе.

Обязанность с высокой вероятностью "уедет" в уровень интеграции.
источник

F

Fagor in Архитектура ИТ-решений
Можно глупый вопрос. Зачем предприятию постороение EA и ISA? Т.е. зачем мне выделять эти компетенции. Не более трех утверждений. Пример: Зачем мне EA и ISA умного города? Ответ: Создание комфортной (экологичной и безопасной), гибкой к изменениям среды обитания.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Istomin
Треугольник Фреге
1) Чтобы смочь отделять знаки от значений от смыслов
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Istomin
1) Чтобы смочь отделять знаки от значений от смыслов
2) отделять нужно чтобы уметь собирать и передавать определённые смыслы, которые отражают такие-то объекты-силы-феномены, и выражаются (называются) таким=то знаком
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Istomin
2) отделять нужно чтобы уметь собирать и передавать определённые смыслы, которые отражают такие-то объекты-силы-феномены, и выражаются (называются) таким=то знаком
3) собирать и передавать нужно для того, чтобы en arche имело живой, гибкий, многовариантный вид.
Это обеспечивает устойчивость в управлении.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Fagor
Можно глупый вопрос. Зачем предприятию постороение EA и ISA? Т.е. зачем мне выделять эти компетенции. Не более трех утверждений. Пример: Зачем мне EA и ISA умного города? Ответ: Создание комфортной (экологичной и безопасной), гибкой к изменениям среды обитания.
Ага?
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Наконец-то кто-то решил создать единый словарик терминов в Российском IT:

https://cdto.wiki/Категория:Тезаурус
источник

F

Fagor in Архитектура ИТ-решений
Вотпрос в тексте. Повторю "Зачем мне развивать компетенции, репозитории и другое EA и ISA на предприятии?" Типичный главный вопрос прежде чем продавать необходимость ЕА которого нет на предприятии.
источник