Size: a a a

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

2020 March 31

SL

Sergey Lukin in Архитектура ИТ-решений
Daria Kaftan
Какие в принципе разбиения вы используете при работе с системами в своих проектах?
domain, sub-domain
capability
service group
cluster
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Sergey Lukin
domain, sub-domain
capability
service group
cluster
это одно разбиение или несколько? или это уже уровни?
источник

SL

Sergey Lukin in Архитектура ИТ-решений
это несколько, разные способы были.
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Daria Kaftan
Коллеги, к вам такой вопрос: как вы разбираетесь в терминологии компонент-модуль-сервис-проч?
В моей системе используется уже функциональное разбиение следующее: система-подсистема-(модуль, сервис, АРМ). То есть, согласуя с ГОСТ 34 система-подсистема-компонент, компонент  - это либо модуль, либо сервис, либо АРМ.
Хочется при этом не запутаться с разбиением на программные модули, среди которых тоже есть подсистемы и сервисы.
Компонент - физически заменяемый элемент (как правило, с точки зрения разработки implementation view, т.е. функция, библиотека, пакет, в общем нечто с документированным API). Сервис - фоновый процесс ОС. Модуль - функционально завершённый узел радиоэлектронной аппаратуры, оформленный конструктивно как самостоятельный продукт :)) А если серьезно, то нечто отдельно поставляемое, наверное и определение можно найти. По ГОСТам: системы, ФПС, программные компоненты и все прочее - умозрительные конструкции, которые следует явно определять через другие элементы
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Maxim Smirnov
Компонент - физически заменяемый элемент (как правило, с точки зрения разработки implementation view, т.е. функция, библиотека, пакет, в общем нечто с документированным API). Сервис - фоновый процесс ОС. Модуль - функционально завершённый узел радиоэлектронной аппаратуры, оформленный конструктивно как самостоятельный продукт :)) А если серьезно, то нечто отдельно поставляемое, наверное и определение можно найти. По ГОСТам: системы, ФПС, программные компоненты и все прочее - умозрительные конструкции, которые следует явно определять через другие элементы
А в каких разбиениях системы участвуют тогда компонент, сервис, модуль?
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Daria Kaftan
А в каких разбиениях системы участвуют тогда компонент, сервис, модуль?
Если я правильно понял, то вопрос в каких представлениях что использовать. Я бы не унифицировал элементы системы в ходе разработки, т.к. они определяются технологиями и довольно разные А Deployment view - это узлы, сервисы, порты, протоколы (ну в кубере еще поды и всё остальное). А как делать функциональную декомпозицию я не знаю (да и никто не знает, есть только разные проработанные частные случаи)
источник

DS

Dmitriy Stolyarov in Архитектура ИТ-решений
Maxim Smirnov
Компонент - физически заменяемый элемент (как правило, с точки зрения разработки implementation view, т.е. функция, библиотека, пакет, в общем нечто с документированным API). Сервис - фоновый процесс ОС. Модуль - функционально завершённый узел радиоэлектронной аппаратуры, оформленный конструктивно как самостоятельный продукт :)) А если серьезно, то нечто отдельно поставляемое, наверное и определение можно найти. По ГОСТам: системы, ФПС, программные компоненты и все прочее - умозрительные конструкции, которые следует явно определять через другие элементы
Сервис может быть не только фоновым процессом ос. Сервис может быть реализован интеграционным компонентом бизнес-приложения.
источник

KG

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

MS

Maxim Smirnov in Архитектура ИТ-решений
Dmitriy Stolyarov
Сервис может быть не только фоновым процессом ос. Сервис может быть реализован интеграционным компонентом бизнес-приложения.
А интеграционный компонент бизнес-приложения это что? Ну, т.е. я не знаю точного определения ни интеграционного компонента ни бизнес-приложения. Может пример какой-нибудь можно привести?
источник

A

Alexie in Архитектура ИТ-решений
Sergey Solomin
всем привет, хочу сделать схему взаимодействия сервисов.
что хочу увидеть: что то похожее на схему для бд для показания связей между сервисами.
подскажите инструмент для создания схемы, никак не могу найти что хочется реализоваться.
сначала думал использовать что то похоже для mind mapping но как то не получается детальную схему
Схема бд показывает связи между схемами, таблицами и т. д. Для создания схемы бд есть встроенные инструменты, смотря какая бд. Также есть в некоторых пакетах для разработки.
В вашем сообщении смешаны понятия схемы бд и схемы связей системных сущностей, это немного разные вещи.
источник
2020 April 01

СС

Сергей Старцев in Архитектура ИТ-решений
Олег Игонин
Есть ещё Gliffy diagram
ну, это браузенрая (в первую очередь онлайн) штука - такого сейчас много... и оно не удобно по следующим причинам:
1) все чаще всего хранится в облаке (и чтобы как-то серьезно совместно работать нужно башлять)
2) на больших/сложных схемах начинает подтормаживать - из-за специфики реализации в браузере (ну, это отдельный холивар)
В этом плане пока остаются актуальными VIsio и yEdgraph... только у них задачи на самом деле разные - визио идет от схемы, и позволяет получить по ней потом аналитику (правда анализ связей штатными средствами не возможен), а yEdgraph идет от семантики/топологии связей и на основе ее позволяет в т.ч. генерить картинку...

Но в целом давно мечтается все-таки о чем-то вроде Archi, тобы была модель, с возможностью ее табличного анализа и виды - для графического представления модели в разных разрезах.
И здесь вопрос - есть ли какие-то инструменты работы с графовыми БД для легкой визуализации данных ("для пользователя") - типа как PowerBI для обычных данных?
источник

OS

Oleg Soroka in Архитектура ИТ-решений
Daria Kaftan
Какие в принципе разбиения вы используете при работе с системами в своих проектах?
источник

СС

Сергей Старцев in Архитектура ИТ-решений
Daria Kaftan
Коллеги, к вам такой вопрос: как вы разбираетесь в терминологии компонент-модуль-сервис-проч?
В моей системе используется уже функциональное разбиение следующее: система-подсистема-(модуль, сервис, АРМ). То есть, согласуя с ГОСТ 34 система-подсистема-компонент, компонент  - это либо модуль, либо сервис, либо АРМ.
Хочется при этом не запутаться с разбиением на программные модули, среди которых тоже есть подсистемы и сервисы.
есть еще кстати волшебное слово "программный комплекс" 😊
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
😂
источник

П

ПашМиш in Архитектура ИТ-решений
@dkaftan да я не против)
источник

П

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

СС

Сергей Старцев in Архитектура ИТ-решений
кстати, приколоная презентация...
http://www.secretchipmunk.com/docs/readysetarchitect.pdf
источник

СС

Сергей Старцев in Архитектура ИТ-решений
не знал, что есть научное название 😊
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Сергей Старцев
не знал, что есть научное название 😊
Ух ты, отлично, теперь у меня тоже есть волшебные буковки!)
источник

DS

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