Архитектура ИТ-решений
13K subscribers
270 photos
27 files
1.07K links
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).

Этот канал не продается, а я не сдаю квартиры/машины/яхты. Будьте, пожалуйста, осторожны!
Download Telegram
Вот такую вот штуку нашел http://pivio.io
Как индустрия, мы склонны предпочитать создание диаграмм, а не моделирование, в первую очередь потому, что барьер для входа относительно низок и это представляется более простой задачей. При построении диаграмм вы обычно создаете одну или несколько отдельных диаграмм, часто в произвольной нотации, используя инструменты (например, Microsoft Visio или доску), которые ничего не понимают в семантике ваших диаграмм...

Simon Brown, Diagramming vs modelling https://structurizr.com/help/modelling
Похоже, что это https://www.amazon.com/Introduction-Solution-Architecture-Alan-McSweeney-ebook/dp/B07P2NCFDQ/ первая толстая книжка по Solution architecture
solution_architecture_approach_to.pdf
1.4 MB
Курс молодого бойца (solution architect-а) от автора книжки Alan McSweeney
Тема, возникающая в связи с декомпозицией монолоита на микросервисы, которую я стараюсь обсуждать с большой осторожностью и которую не вынес на вебинар https://mxsmirnov.com/2019/05/07/monolith2microservices/

Почему DDD или capabilities based подходы при выделении микросервисов порой вызывают разочарование? Потому что идти надо не от данных и не от функционала, а со стороны пользователя. Точнее, наиболее близкого к нему API. Есть правильный REST API, между front- и backend-ом, корректно использующий методы HTTP и представляющий нормальную моделью ресурсов - можно выделять функционал, а если нет, то ничего не получится. Ограниченные контексты может и неплохая идея, но воплощается она в REST API, плюс/минус события
Когда-то, приступая к изучению DDD я рассчитывал найти набор простых, но полезных паттернов, типа Dimensional modeling Ральфа Кимбалла https://www.kimballgroup.com/1997/08/a-dimensional-modeling-manifesto/ Простая идея, раскрутившая на определенном этапе, многомиллиардный бизнес построения корпоративных хранилищ данных (Хотя непосредственно Кимбалл говорил, что централизованное хранилище не нужно). Надеюсь, что и в DDD когда-нибудь появятся свои Инмоны и Кимбаллы
Меня часто достают идеями типа единой модели данных организации или единой базы данных, в которой будет хранится всё и в правильном формате. Пришла на ум такая метафора. Представьте, что некоторая страна, изучив свою карту решила, что слишком большая часть её территории занята водой: реки, озера, внутренние моря и т.д. В рамках проекта консолидации водных ресурсов руководители страны принимают решение о едином источнике воды. Пусть это будет море, оно самое большое и все реки, озера и прочие водные ресурсы решено слить в море и осушить. А за водой теперь все будем ходить до моря, причем по очереди

Логика консолидаторов данных довольно похожа на эту
w194.pdf
727.3 KB
Хочу до сентября провести митап с условным названием Архитектура предприятия лайт. В основном, вот по этой бумаге Using Agile Practices in Enterprise Architecture от The Open Group (май 2019) Предложения выступить по какому-либо из её разделов: сдвиг парадигмы, гибкие практики и пр. приветствуются! Пишите @mxsmirnov ;-)
Поделюсь заметкой из канала DocOps
Forwarded from DocOps
​​Курс по документированию REST API на русском языке.

Тут случилось что-то невероятное. Курс Тома Джонсона по документированию REST API переведён на русский язык. Денис Старков сделал это сам, один, за полгода работы.

Оригинальный Documenting APIs: A guide for technical writers and engineers — наверное, самый полный и полезный открытый курс по документированию. Он рассчитан на технических писателей, разработчиков и студентов. Для техписателей этот курс — точка входа в документирование кода и API, очень интересную область работы, за которую ещё и неплохо платят. Разработчики из этого курса научатся структурировать информацию и понятно описывать свой код и API.

Читайте переведённый курс по документированию REST API, рекомендуйте его коллегам, ставьте звёзды репозиторию. Шлите пуллреквесты с правками, наконец. :)
Очень даже познавательный такой лонгрид о комплексном мониторинге https://brunonetid.github.io/2019/07/09/camel-observability-openshift.html Почитаю еще раз на досуге, более внимательно
Поделюсь записью выступления @evgeniy_nikonorov о том, как "продать" идею практики архитектурного проектирования на проекте, с примерами того, что работает, а что не работает и на что стоит обратить особое внимание: https://youtu.be/mabCE99ACBQ
Существуют, как минимум, три разные вещи, названные одним и тем же словом #ArchOps. Про верую рассказывает википедия в статье про DevOps https://en.wikipedia.org/wiki/DevOps#ArchOps Я бы назвал это model-driven development + автоматизированная сборка и развертывание. Вторая идея описана в блоге Archimate https://www.archimatetool.com/blog/2016/11/03/archops-a-new-paradigm-for-ea-toolsets/ и заключается в использовании практик работы с версиями, распространившимся с появлением git, для описания [целевой] архитектуры
… no “central model” because you can choose to create multiple copies of this model and sync them
И третье, про EAM + AIOps, не то чтоб описано, скорее очерчено здесь: https://www.bloorresearch.com/technology/archops/
Истинным ценителям archimate большое количество любимых картинок https://www.hosiaisluoma.fi/blog/archimate-cookbook/ Мне кажется, что особенно customer journey удался (см. рисунок)
Автор XP Кент Бек продолжает на медиуме истории(с картинками на салфетке) про “waiters” и “changers” и изменения ПО затрагивающие его структуру или только поведение https://medium.com/@kentbeck_7670/software-design-is-human-relationships-part-3-of-3-changers-changers-20eeac7846e0
Вопрос к вам, уважаемые подписчики! Кто-нибудь, (кроме lamoda, см. ссылки [1,2] внизу сообщения) использует в своем энтерпрайзе технологический радар https://www.thoughtworks.com/radar/how-to-byor или какой-либо похожий инструмент?
--
[ 1 ] LAMODA TECHNOLOGY RADAR - 2018.11
[ 2 ] Статья на хабре