Пошла жара вокруг ДДД. Имхо когда мы говорим о какой-то практике, нужно четко разделять:
1. Академическую часть
2. Приклад
3. Контекстно-зависимое применение

Поясню на примере ДДД.

Академическая часть - это Эванс, Вернон, работы о самом ДДД, теория сложных адаптивных систем, моделирование, системное мышления и проячее. Академическая часть нужна для того чтобы:
- развивать фундаментальные основы, независимо от приклада
- обучать прикладным вещам (да, для этого важно понимать, на чем они основаны)
2. Приклад. Например, - дизайн организационной структуры, принятие управленческих решений на основе типов доменов (что инхаус разрабатывать, что отдать на аутсорс), проектирование микросервисного решения
3. Контексто-зависимый приклад - например, Банк, CRM, ритейл, Поиск. Для применения здесь не нужно даже знать терминологию ДДД, и даже вообще знать что есть какое-то ДДД, но тому кто будет проектировать или строить модели, проводить совместное исследование домена, безусловно, нужны знания и на академическом и на прикладном уровне (а вот контекстно-зависимый приклад уже не так важен, его нужно структурировать усилиями участников совместной практики).

И так с любой практикой, имхо. Есть популярный узкоспециализированный приклад, есть принципы и основы на которых он построен и их знание позволяет подстраиваться под любые специализации в рамках области определения и есть еще более фундаментальные основы, которые дают понимание самых базовых принципов.

Менеджмент становится намного проще при знании мат аппарата теории массового обслуживания (теории очередей) просто потому, что знание что там в числителе, что в знаменателе, что от чего зависит позволяет быстро оценить зависимости по переменным для любого контекста. Это не обязательно, конечно, и не всем нужно, но для обучения менеджменту (в моем понимании - и архитектуре), для понимания как работать с потоком создания ценности, это имхо прям must have знания.

Туда же микросервисы, где для создания написания кода сервисов важнее прикладные навыки, а для проектирования уже важны и фундаментальные знания, причем чем в большем спектре они перейдут в проф. интуицию, тем лучше.

Буду рад обсудить в коментах.

А вы когда собеседуете разработчиков или архитекторов на продукты/проекты, построенные по принципу распределенной системы/микросервисного решения, вы какие вопросы на собеседовании задаете?

Или какие вопросы задавали вам, тем, кто проходил собеседования?

Думаю это многим может помочь составить траекторию обучения с учетом реальной (не гипотетической) потребности реальных проектов и продуктов.

Ольга пишет диссер на тему самоактуализации в сфере IT, попросила помочь, если кому интересно можете пройти тест.
👇

Приглашаю пройти участие в исследовании в сфере самореализации у IT-специалистов.

✅ по его результатам вы сможете узнать о том, насколько в вас развиты: гибкость, креативность, синергия и другие важные качества для реализации себя в IT сфере.

Опрос анонимный, состоит из небольшой анкеты и 2 тестов.
Займёт примерно 20 минут.

https://docs.google.com/forms/d/e/1FAIpQLSdWL8HklTaEr02iWzl_YclfexJjiEmvpuGEz5tz9KzLAmFVSw/viewform?usp=sf_link

Если будут вопросы по ходу тестирования - задай их мне, я подскажу, отвечу (@OlgaEgelskaya)
Благодарю за уделенное время!

Мы решили объединить усилия в новом коллективном телеграм-канале, посвященном вопросам ИТ-архитектуры и управления процессами разработки.

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

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

За последнее время у нас выкристаллизовался коллектив единомышленников, который решил объединить усилия для разрешения этого противоречия.

Канал самоуправляется консенсусом коллегии из четырех человек: @sergey486 , @GKruglov , @elukianov и @emacsway . Круг авторов этим не ограничивается. Если вы поддерживаете наши устремления и обладаете необходимыми навыками, то можете пополнить наш авторский коллектив (обращайтесь к любому из списка).

Для обсуждений создан чат: https://tttttt.me/ru_arc_chat

Это только первый шаг. Уже сейчас мы продумываем принципы, которые позволят коллективизировать работу над архитектурными руководствами, а так же над Reference Architectures/Applications. Есть и другие идеи, но о них говорить пока еще преждевременно. В общем, должно получиться интересно.

27-го выступаю на DotNext (очно), кто идет?)

https://dotnext.ru/talks/1d81350f83a040519d454f92a5164ad8/

Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов

#DDD #MSA

Всем привет 👋
В рамках книжного клуба { между скобок } мы организовали интервью с тем самым Мартином Клеппманном книгу которого мы прочитали. Обсудим книгу, поговорим про будущее data systems и о новых исследованиях Мартина:
📍 https://www.inkandswitch.com/local-first/
📍https://automerge.org/

Встречаемся 30 июня в 20:00 по мск

Martin Kleppmann is a researcher in distributed systems and security at the University of Cambridge, and author of the bestselling book Designing Data-Intensive Applications (O'Reilly Media). Previously he was a software engineer and entrepreneur, co-founding and selling two startups, and working on large-scale data infrastructure at LinkedIn.

Ссылка на подключение будет чуть позже в чате https://tttttt.me/backend_megdu_skobkah

Также закидывайте ваши вопросы для Мартина в гугл форму https://forms.gle/ZCGNfZ42JJDNsEcd8

Кто дотнет умеет, норм пример в статье?

Quickly find out the log correlation in your microservice with the Dotnet example

https://betterprogramming.pub/microservice-tracing-log-in-the-distributed-system-96f49bcb7bd

UPD от @Robo_Net (спасибо):

«В доке дотнета есть более актуальная версия, которая входит в стандартную библиотеку https://docs.microsoft.com/en-us/dotnet/core/diagnostics/distributed-tracing-instrumentation-walkthroughs и по ссылочкам внизу тоже много примеров. Если конечно нужен актуальный дотнет, а не под старый фреймворк»

Эффект траектории

Если когда-то в большом монолите было принято неподходящее инженерное решение, то, скорее всего, оно уже распространилось по всей системе, а его выкорчевывание требует значительных затрат и переходного периода, когда стабильность решения будет под угрозой. Само наличие этого решения провоцирует дальнейшее развитие последовательности неудачных решений и компромиссов.

Микросервисы — это еще и способ пересмотреть ранее принятые неподходящие и/или устаревшие решения и избавиться от их негативного влияния сегодня и, что более ценно, завтра. Если же мы снова примем неподходящее решение, то скоуп его негативных последствий будет уже и исправить его будет дешевле.

Рассказал про Intelligent Swarming
В конце концов всем нам приходится заниматься поддержкой того, что пилим, вот есть такой подход к суппорту, который в целом должен (но не обязан) снизить нагрузку на ключевых экспертов с одновременным ускорением решения проблем)

https://www.youtube.com/watch?v=zfnuFSAqC40

Тут мануалы:
https://www.serviceinnovation.org/intelligent-swarming/

И вдогонку занятная преза

«AWS DevOps Series Module 7 SRE and Incident Management»

Без каких инструментов современному веб проекту будет не просто?

Для домашних проектов все эти рекомендации скорее оверхед чем польза, но чем серьезнее становится проект и аудитория - тем важнее эти советы и правила.

Никогда не забывайте делать резервные копии.
⁃ Бекап должен быть максимально полезным, а значит содержать в себе только те данные, которые заново воспроизвести будет не возможно или долго-дорого.
⁃ Бекап должен быть подтвержден тестами на работоспособность сохраненной копии данных.
⁃ Бекап должен быть эксплуатирован, развертка из бекапа должна проверяться с какой-то переодичностью
⁃ Бекап должен быть безопасным. В идеале зашифрован.
⁃ Используйте специальный софт, а не bash скриптики с кроном. (хотя это тоже работает до определенного момента), но лучше - https://habr.com/ru/company/flant/blog/420055/
⁃ Используйте несколько источников хранения бекапов. Бывает так, что одного может не оказаться в какой-то момент (не доверяйте слепо облакам).

Фиксируйте ошибки приложения проактивно.
⁃ Если приложение упало, вы можете об этом никогда не узнать, если не мониторите access логи сервера.
⁃ Если приложение работает не корректно у клиента, при этом это современное spa приложение, вы об этом не узнаете примерно никогда, если не настроите правильный мониторинг такого поведения (читай сбор ошибочного поведения со стороны фронтенда) или до тех пор пока к вам не придет сам пользователь с жалобой (нужно дать возможность сообщать о багах из веб морды).
⁃ Хорошим тоном и практикой является подключение публичной sentry для фиксации ошибок, например вот так можно начать - https://habr.com/ru/post/508686/

Мониторинг работы сервера и приложения.
⁃ Чем больше всего нужно, тем больше за этим нужно наблюдения, к сожалению.
⁃ Хорошим стартом будет базовый grafana + prometheus + экспортеры метрик для фиксации работы приложения, сервера и инфраструктурных слоев.
⁃ Если есть опыт и желание, можно обойтись zabbix.
⁃ Уведомление о том, что сервер сломался и(или) что-то подходит к пиковым характеристикам можно реализовать либо через туже grafana, либо через alertmanager.
⁃ Использования облачных grafana или других инструментов для сбора и анализа метрик тоже хорошая история, если вы им доверяете (!)
⁃ Логи кстати тоже надо мониторить, тут подойдут какие-нибудь graylog или loki, или еще что-то ибо решений прям очень много.
⁃ Ну и внутреннего мониторинга не достаточно, нужно проверять что приложение работает из вне. Для этого есть saas сервисы, ну или можно реализовать самостоятельно.

⬇️ Далее

Привет!
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.

🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты выступлений, важность которых была осознана уже после;
— ответят на вопросы из зала или из формы на сайте.

📍Программа и регистрация: https://archconf.ru/recap-27-07-22

Тем временем уже можно подавать заявки на выступление на ArchDays (https://archdays.ru).

Темы в этом году более общие, но при этом, как нам показалось, они совместно полны и взаимоисключающие (насколько это возможно):

1.Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре/развитие в архитектора
5. Soft skills

Если у вас тема огонь и не подходит под тематики, пишите мне, разберемся, как это у нас тематики под огненную тему не нашлось 🖖

💬 "These were elucidated in the mid-70s by Yourdon & Constantine in "Structured Design" and haven't changed. Their argument goes like this:

1. We design software to reduce its cost.
2. The cost of software is ≈ the cost of changing the software.
3. The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that).
4. The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then…
5. Coupling between elements of a design is this propensity for a change to propagate.
6. So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling.

(This skips loads of interesting stuff, but I'm just trying to set up the argument for why rapid decomposition of a monolith into micro-services is counter-productive.)"

-- "Monolith -> Services: Theory & Practice" by Kent Beck

Недавно в чате было обсуждение микрофронтендов, свежая статья в тему:

https://medium.com/@anilcanerciyes/microfrontends-module-federation-for-runtime-integration-2bdac86fcf0f

Преза моего недавнего выступления на DotNext про то, что можно получить из модели предметной области представленной в нотации Event Storming.

Микросервисов тоже слегка рукавом коснулся.

Monolith First строится вокруг простой идеи — восприятие монолита как прототипа.