Size: a a a

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

2017 May 23

MS

Maxim Smirnov in Архитектура ИТ-решений
Gennadiy Kruglov
На это есть ответ в SOA: Service Autonomy :) Каждый сервис должен монопольно владеть своими ресурсами, в том числе данными. Данные должны быть инкапсулированы в сервисах. Если говорить о MonolithFirst, то на начальном этапе данные разных сервисов могут жить в одной базе, но решение нужно дизайнить так, чтобы данные  можно было быстро засплитить и перенести вместе с сервисом. Я сам так делал.
Где-то так. Есть у меня тут на примете одна большая MS SQL-ая БД - потенциальный кандидат на расщепление. Боюсь, правда, что реальность окажется существенно глубже и драматичней, чем общий принцип :)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Maxim Smirnov
Где-то так. Есть у меня тут на примете одна большая MS SQL-ая БД - потенциальный кандидат на расщепление. Боюсь, правда, что реальность окажется существенно глубже и драматичней, чем общий принцип :)
Могу поделиться своей практикой. Основная идея в том, что если дизайнить решение сразу с прицелом на расщепление и принуждать всех владельцев сервисов (которые пока живут в монолите) взаимодействовать только через контракты, то расщепить будет не так уж сложно. Но если решение изначально - монолит с макаронами внутри, то иногда проще использовать Legacy Wrapper, то есть выкинуть и переписать :)
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Gennadiy Kruglov
Могу поделиться своей практикой. Основная идея в том, что если дизайнить решение сразу с прицелом на расщепление и принуждать всех владельцев сервисов (которые пока живут в монолите) взаимодействовать только через контракты, то расщепить будет не так уж сложно. Но если решение изначально - монолит с макаронами внутри, то иногда проще использовать Legacy Wrapper, то есть выкинуть и переписать :)
Рефакторинг на сервисы более реальный вариант при некотором нарушении dry. Остановить бизнес на "все переписать" никто не даст.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Andrei Soloschak
Рефакторинг на сервисы более реальный вариант при некотором нарушении dry. Остановить бизнес на "все переписать" никто не даст.
Ключевое слово "иногда". Иногда удобнее переписать. Legacy  Wrapper как раз и говорит о том, что решение замещается по частям, постепенно. При этом, ничего не мешает переносить полезный код из унаследованного решения в новое.
источник

MS

Maxim Shalomovich in Архитектура ИТ-решений
Gennadiy Kruglov
На это есть ответ в SOA: Service Autonomy :) Каждый сервис должен монопольно владеть своими ресурсами, в том числе данными. Данные должны быть инкапсулированы в сервисах. Если говорить о MonolithFirst, то на начальном этапе данные разных сервисов могут жить в одной базе, но решение нужно дизайнить так, чтобы данные  можно было быстро засплитить и перенести вместе с сервисом. Я сам так делал.
Насколько я понимаю, монопольное владение ресурсами и инкапсуляция доступа к данным через дата-сервисы никак не принуждает к их раздельному хранению в разных БД. По сути принципиальным является именно инкапсуляция доступа к ним (как на чтение, так и на запись), в том числе - чтобы избежать лишних зависимостей, пусть и инвертированных.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Maxim Shalomovich
Насколько я понимаю, монопольное владение ресурсами и инкапсуляция доступа к данным через дата-сервисы никак не принуждает к их раздельному хранению в разных БД. По сути принципиальным является именно инкапсуляция доступа к ним (как на чтение, так и на запись), в том числе - чтобы избежать лишних зависимостей, пусть и инвертированных.
Конечно. И в то же время, если сервис монопольно владеет собственными ресурсами, то в целях масштабирования есть возможность относительно недорогой миграции данных этого сервиса в другие базы. Больше того, на начальном этапе удобней иметь как можно меньше баз. Ремарка, дата-сервисы - это из таксономии SOA :), в таксономии Microservices дата-сервисов нет.
источник

DS

Dmitry Sotnikov in Архитектура ИТ-решений
#whois Дмитрий Сотников, Системный аналитик, разработчик. Славнефть.
источник

SS

Sofia Suslova in Архитектура ИТ-решений
#whois Суслова Софья, аналитик. Корус консалтинг
источник

CF

Constantine Fomchenkov in Архитектура ИТ-решений
#whois Константин Фомченков product/project manager на проекте mos.ru
источник

R

Roman in Архитектура ИТ-решений
Constantine Fomchenkov
#whois Константин Фомченков product/project manager на проекте mos.ru
product/project manager - это ж две противоположности)
источник

CF

Constantine Fomchenkov in Архитектура ИТ-решений
Roman
product/project manager - это ж две противоположности)
применяются по необходимости)
источник

CF

Constantine Fomchenkov in Архитектура ИТ-решений
в основном продакт
источник

AV

Anton Voloshin in Архитектура ИТ-решений
доктор Джекилл и мистер Хайд
источник

CF

Constantine Fomchenkov in Архитектура ИТ-решений
Anton Voloshin
доктор Джекилл и мистер Хайд
все так
источник

DI

Denis Izmaylov in Архитектура ИТ-решений
Внимание вопрос. Как проектирование и изменении архитектуры взаимодействует с системными и бизнес-требованиями?
источник

DI

Denis Izmaylov in Архитектура ИТ-решений
Согласно ALM - проектирование архитектуры получает на вход требования:
источник

DI

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

DI

Denis Izmaylov in Архитектура ИТ-решений
Но в каком виде?
источник

MS

Maxim Shalomovich in Архитектура ИТ-решений
Denis Izmaylov
Но в каком виде?
В смысле, форма?
источник

CF

Constantine Fomchenkov in Архитектура ИТ-решений
Denis Izmaylov
Но в каком виде?
фт и нфт, как их передавать - кому как удобнее я испльзовал google doc и gitlab
источник