Forwarded from DDDevotion
Читал вчера статью Маттиаса Верраеса про Segregated Event Layers и внезапно узнал, что это серия статей о паттернах в контексте DDD и Messaging Architecture
https://verraes.net/2019/05/ddd-msg-arch/ Enjoy!
https://verraes.net/2019/05/ddd-msg-arch/ Enjoy!
Mathias Verraes' Blog
DDD and Messaging Architectures
An overview of my different series on patterns in distributed systems.
Forwarded from Code of Architecture
На последнем стриме по этой книге рассмотрим всю третью часть Impact. А именно разберем три главы, посвященные реализации эволюционной архитектуры. Среди тем, которые обсудим:
— рекомендации для построения эволюционной архитектуры;
— подводные камни и антипаттерны на пути к эволюционной архитектуре;
— влияние техники, бизнеса, орг.структуры и команд на возможность реализации эволюционной архитектуры.
Эфир проведем вмест с Сергеем Барановым, организатором и создателем конференции ArchDays, а еще автором Agile Mindset и телеграм-канала «Микросервисы — русскоязычное сообщество».
Не забудьте подписаться на уведомления нашего ютуб-канала, чтобы не пропустить начало.
Please open Telegram to view this post
VIEW IN TELEGRAM
Приходите выступать 👌
ArchDays.ru
(И спасибо всем, кто уже прислал заявки, за июль планируем больше половины программы собрать)
ArchDays.ru
(И спасибо всем, кто уже прислал заявки, за июль планируем больше половины программы собрать)
«Ограниченный контекст — это граница модели, а модель применима только в своем ограниченном контексте. Ограниченные контексты реализуются в независимых проектах и решениях, что позволяет каждому ограниченному контексту иметь собственный жизненный цикл разработки. И наконец, ограниченный контекст должен быть реализован одной командой разработчиков, и, следовательно, он также является границей владения.»
Скончался Кевин Митник. Уходят легенды.
Его книгу «Искусство обмана» я прочел около 20 лет назад и она до сих пор стоит у меня на книжной полке.
Именно эта книга в то время проявила во мне интерес к взлому и безопасности и выступила катализатором к изучению всего, что касается сетей.
Я лазил по хакерским сайтам, читал журналы, использовал и сам писал софт для сканирования сетей, спуфинга, дебажил игры, заменяя значения в регистрах, учился писать эксплоиты и разбирал по косточкам найденные в сети. Полученный тогда опыт и знания до сих пор приносят дивиденды, позволяют при проектировании где-то на уровне подсознания видеть потенциальные лазейки в безопасности систем.
Это приятные воспоминания об увлекательных временах, а началось все с одной единственной книги Кевина Митника.
Покойся с миром.
Его книгу «Искусство обмана» я прочел около 20 лет назад и она до сих пор стоит у меня на книжной полке.
Именно эта книга в то время проявила во мне интерес к взлому и безопасности и выступила катализатором к изучению всего, что касается сетей.
Я лазил по хакерским сайтам, читал журналы, использовал и сам писал софт для сканирования сетей, спуфинга, дебажил игры, заменяя значения в регистрах, учился писать эксплоиты и разбирал по косточкам найденные в сети. Полученный тогда опыт и знания до сих пор приносят дивиденды, позволяют при проектировании где-то на уровне подсознания видеть потенциальные лазейки в безопасности систем.
Это приятные воспоминания об увлекательных временах, а началось все с одной единственной книги Кевина Митника.
Покойся с миром.
У меня окончательно оформилось предложение по точечному аудиту/исследованию микросервисного архитектурного решения :)
Аудит затрагивает:
- степень соответствия выбранного стиля бизнес-модели и потребностям рынка
- степень соответствия орг. структуры микросервисному архитектурному стилю
- степень соответствия компетенций
- степень соответствия процессов горизонтального и вертикального взаимодействия
- степень соответствия процессов управления архитектурной целостности и развития архитектуры
- степень соответствия процессов управления тех долгом
- степень удовлетворения требованиям и атрибутам качества
А по итогу идет перечень дисфункций/ и стратегия их устранения.
«это была славная охота» :)
Скоро предложение будет опубликовано, пока все собирал и систематизировал получилось материала на книгу, более 200 страниц только текста :)
Этот аудит я уже проводил много-много раз в рамках корпоративных контрактов, многие выводы есть в моем курсе по микросервисам и там чего только не было, что только не называют микросервисами.
Огромный монолит просто положили в докер - микросервис, компоненты с сильнейшими зависимостями, множество пустых компонентов, которые работают с единой базой и вся логика на общих для всех хранимках, тотальное смешение сущностей предметный областей. Общее регрессионное ручное тестирование на несколько недель. Отсутствие атрибутов качества как таковых, что приводит к постоянному пожаротушению, некорректное определение атрибутов качества. Стратегия, которая затрагивает только орг дизайн и не затрагивает архитектуру вообще (да-да и такое бывает).
Версию лайт для самопроверки думаю выложить в паблик, но она еще не готова для публичного доступа.
Что побудило?
Некоторый застой в практиках архитектурного ассесмента. Если погуглить, то толком кроме ATAM ничего и не находится, причем статьи 15-летней давности. А индустрия не стоит на месте.
Еще планирую собрать рабочую группу из активистов для проработки деталей.
Все это будет, периодически буду публиковать новости на эту тему, всем хорошего дня :)
Аудит затрагивает:
- степень соответствия выбранного стиля бизнес-модели и потребностям рынка
- степень соответствия орг. структуры микросервисному архитектурному стилю
- степень соответствия компетенций
- степень соответствия процессов горизонтального и вертикального взаимодействия
- степень соответствия процессов управления архитектурной целостности и развития архитектуры
- степень соответствия процессов управления тех долгом
- степень удовлетворения требованиям и атрибутам качества
А по итогу идет перечень дисфункций/ и стратегия их устранения.
«это была славная охота» :)
Скоро предложение будет опубликовано, пока все собирал и систематизировал получилось материала на книгу, более 200 страниц только текста :)
Этот аудит я уже проводил много-много раз в рамках корпоративных контрактов, многие выводы есть в моем курсе по микросервисам и там чего только не было, что только не называют микросервисами.
Огромный монолит просто положили в докер - микросервис, компоненты с сильнейшими зависимостями, множество пустых компонентов, которые работают с единой базой и вся логика на общих для всех хранимках, тотальное смешение сущностей предметный областей. Общее регрессионное ручное тестирование на несколько недель. Отсутствие атрибутов качества как таковых, что приводит к постоянному пожаротушению, некорректное определение атрибутов качества. Стратегия, которая затрагивает только орг дизайн и не затрагивает архитектуру вообще (да-да и такое бывает).
Версию лайт для самопроверки думаю выложить в паблик, но она еще не готова для публичного доступа.
Что побудило?
Некоторый застой в практиках архитектурного ассесмента. Если погуглить, то толком кроме ATAM ничего и не находится, причем статьи 15-летней давности. А индустрия не стоит на месте.
Еще планирую собрать рабочую группу из активистов для проработки деталей.
Все это будет, периодически буду публиковать новости на эту тему, всем хорошего дня :)
1 августа в 19:00 пройдет митап ArchDays: «Проектирование БД: От NF к денормализации данных»
Спикер: Антон Цитульский — Старший разработчик в Тинькофф.
На митапе Антон расскажет:
— о плюсах и минусах нормальных форм (NF);
— когда пора денормализовывать схему и как это сделать;
— как развивать схему БД с учетом роста данных и контекста бизнес-домена.
А в конце встречи обсудим тему вместе с участниками митапа.
💎 Регистрируйтесь: https://archconf.ru/meetup-010823
Спикер: Антон Цитульский — Старший разработчик в Тинькофф.
На митапе Антон расскажет:
— о плюсах и минусах нормальных форм (NF);
— когда пора денормализовывать схему и как это сделать;
— как развивать схему БД с учетом роста данных и контекста бизнес-домена.
А в конце встречи обсудим тему вместе с участниками митапа.
💎 Регистрируйтесь: https://archconf.ru/meetup-010823
Микросервисы / распределенные системы
1 августа в 19:00 пройдет митап ArchDays: «Проектирование БД: От NF к денормализации данных» Спикер: Антон Цитульский — Старший разработчик в Тинькофф. На митапе Антон расскажет: — о плюсах и минусах нормальных форм (NF); — когда пора денормализовывать схему…
Очень много регистраций, так что настроили параллельно трансляцию в ютуб, кому так удобнее можно туда сразу идти 🙂
https://youtube.com/live/mCpguC88Amk?feature=share
https://youtube.com/live/mCpguC88Amk?feature=share
YouTube
Проектирование БД: От NF к денормализации данных. Антон Цитульский
Выступление в рамках конференции ARCHDAYS: https://archconf.ru/arch
На митапе Антон рассказал:
— о плюсах и минусах нормальных форм (NF);
— когда пора денормализовывать схему и как это сделать;
— как развивать схему БД с учетом роста данных и контекста бизнес…
На митапе Антон рассказал:
— о плюсах и минусах нормальных форм (NF);
— когда пора денормализовывать схему и как это сделать;
— как развивать схему БД с учетом роста данных и контекста бизнес…
Хочу выступить сам, выбирайте тему (множественный выбор):
Anonymous Poll
15%
Отличительные особенности EA в agile/не agile
38%
Организация базового арх. процесса для поддержки самоорганизации
20%
История возникновения микросервисов, отличие от SOA
38%
Связь бизнеса, процессов и архитектуры в микросервисах
52%
Общий процесс проектирования микросервисов
47%
Быстрое восстановление основных знаний об архитектуре
3%
Предложу тему в комментариях
Тема следующего митапа - «Общий процесс проектирования микросервисов».
Дату и время анонсируем позже. А пока…
Напишите ваши вопросы или проблемы с проектированием заранее в комментариях к этому посту, мне это поможет лучше попасть в ожидания 🎯
Дату и время анонсируем позже. А пока…
Напишите ваши вопросы или проблемы с проектированием заранее в комментариях к этому посту, мне это поможет лучше попасть в ожидания 🎯
Статья про надежный обмен данными между сервисами при использовании стриминговой базы данных.
(В посте есть ссылка на статью с описанием стриминговых баз данных и зачем они нужны).
https://www.iambobur.com/post/reliable-microservices-data-exchange-with-streaming-database
Меня эта тема заинтересовала, потому что как минимум в одном текущем проекте увидел явную потребность. Кто использует/использовал, напишите в комментарии или в личку какую базу используете и в каком контексте, можно устроить митап на тему стриминговых баз данных и их применения.
(В посте есть ссылка на статью с описанием стриминговых баз данных и зачем они нужны).
https://www.iambobur.com/post/reliable-microservices-data-exchange-with-streaming-database
Меня эта тема заинтересовала, потому что как минимум в одном текущем проекте увидел явную потребность. Кто использует/использовал, напишите в комментарии или в личку какую базу используете и в каком контексте, можно устроить митап на тему стриминговых баз данных и их применения.
Название: "Код Зла"
Сценарий:
Начало
Туманный городской пейзаж. Мы видим старое здание с табличкой "Software Corp". Главный герой - Алекс, молодой архитектор ПО, приезжает на новое место работы, где ему поручают создание новой банковской системы.
Сюжет 1: Таинственное наследие
Алекс знакомится с командой и узнает, что последний архитектор, работавший над этим проектом, исчез без следа. Оставив лишь заметку: "Разберитесь с доменами... или они разберутся с вами".
Сюжет 2: Пробуждение домена
Алекс начинает анализировать предметную область. Каждый раз, когда он ошибается в понимании домена, странные вещи начинают происходить: свет мерцает, программное обеспечение ведет себя непредсказуемо, а коллеги слышат шепот неведомой сущности в коридорах.
Сюжет 3: Встреча с предыдущим архитектором
Алекс случайно обнаруживает потайную дверь в офисе. За ней - старый серверный кластер и дневник прошлого архитектора. Дневник рассказывает о том, как домены, неправильно оформленные и понятые, стали живыми сущностями, стремящимися воплотить свои правила и инварианты в реальном мире.
Сюжет 4: Борьба и понимание
Алекс решает воспользоваться DDD, чтобы "укротить" домены. Его команда, преодолевая страх, ведет глубокие интервью с экспертами домена, определяя ограниченные контексты и настоящие потребности пользователей. С каждым новым открытием, мистическая активность в офисе уменьшается.
Сюжет 5: Конечная битва
Алекс создает идеальную модель, где каждый агрегат и сущность на своем месте. Однако, последний домен, самый сложный и неясный, начинает активно сопротивляться. Свет гаснет, здание начинает трястись. Алекс, вдохновленный духом прошлого архитектора, проводит мастер-класс по DDD, и в результате выявляется последний недостающий элемент. Сущность, терроризировавшая их, успокаивается и становится частью их системы.
Конец
Солнце вновь светит над "Software Corp". Алекс и его команда понимают, что настоящая магия DDD - в понимании и сотрудничестве. Вдали, туманный силуэт предыдущего архитектора благодарно кивает им и исчезает.
Титры.
(с) ChatGPT
Сценарий:
Начало
Туманный городской пейзаж. Мы видим старое здание с табличкой "Software Corp". Главный герой - Алекс, молодой архитектор ПО, приезжает на новое место работы, где ему поручают создание новой банковской системы.
Сюжет 1: Таинственное наследие
Алекс знакомится с командой и узнает, что последний архитектор, работавший над этим проектом, исчез без следа. Оставив лишь заметку: "Разберитесь с доменами... или они разберутся с вами".
Сюжет 2: Пробуждение домена
Алекс начинает анализировать предметную область. Каждый раз, когда он ошибается в понимании домена, странные вещи начинают происходить: свет мерцает, программное обеспечение ведет себя непредсказуемо, а коллеги слышат шепот неведомой сущности в коридорах.
Сюжет 3: Встреча с предыдущим архитектором
Алекс случайно обнаруживает потайную дверь в офисе. За ней - старый серверный кластер и дневник прошлого архитектора. Дневник рассказывает о том, как домены, неправильно оформленные и понятые, стали живыми сущностями, стремящимися воплотить свои правила и инварианты в реальном мире.
Сюжет 4: Борьба и понимание
Алекс решает воспользоваться DDD, чтобы "укротить" домены. Его команда, преодолевая страх, ведет глубокие интервью с экспертами домена, определяя ограниченные контексты и настоящие потребности пользователей. С каждым новым открытием, мистическая активность в офисе уменьшается.
Сюжет 5: Конечная битва
Алекс создает идеальную модель, где каждый агрегат и сущность на своем месте. Однако, последний домен, самый сложный и неясный, начинает активно сопротивляться. Свет гаснет, здание начинает трястись. Алекс, вдохновленный духом прошлого архитектора, проводит мастер-класс по DDD, и в результате выявляется последний недостающий элемент. Сущность, терроризировавшая их, успокаивается и становится частью их системы.
Конец
Солнце вновь светит над "Software Corp". Алекс и его команда понимают, что настоящая магия DDD - в понимании и сотрудничестве. Вдали, туманный силуэт предыдущего архитектора благодарно кивает им и исчезает.
Титры.
(с) ChatGPT
Опрос, касается только статей, не книг и только архитектуры/дизайна.
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Anonymous Poll
24%
Быстро находите ответ
36%
Долго и упорно ищите и в итоге находите ответ
22%
Чаще не находите ответ
2%
Ни разу не смогли найти ответ
16%
Посмотреть результаты
Микросервисы / распределенные системы
Опрос, касается только статей, не книг и только архитектуры/дизайна.
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Интересно посмотреть на результат вот с какой точки зрения: в сумме второй и третий ответы дают больше половины. То есть, вообще-то, несмотря на бесчисленное множество и бесконечное обилие материалов, найти что-то конкретное достаточно сложно, а если возможно, то затратно по времени.
В таких условиях выглядит так, что лучше тактикой будет стараться сократить необходимость использования поисковых систем, тут подходов много и все они затратные, но все же:
1. Максимально вкладываться в образование (в широком смысле). Часто из-за высокой загрзуки на это остается мало времени, а именно это дает возможность сократить множество нерешаемых задач
2. Формировать внутренние и внешние сообщества, где вбросил вопрос и кто-то может знать конкретный вектор поиска ответа или ответ
3. Развивать практические навыки на различных хакатонах и за счет прототипирования, – теория без практики быстро выветривается из головы
4. Расширять кругозор на митапах и конференциях, – здесь как раз идеи того, что можно попробовать сделать на практике; важно то, что вы знаете с кем можно обсудить проблему детальнее, этот человек буквально перед вами
5. Отдавать предпочтение книгам, – все-таки долгое погружение в один контекст дает лучший эффект, чем сотня разрозненных статей. Статьи пишут те, кто читает книги 🙂 Это я, конечно, упростил, но, скорее всего, именно книги помогут чаще находить ответы самостоятельно, потому что они развивают мысль, а статьи все ж чаще дают конкретный ответ, без более широго контекста, подводки, рассуждений, выводов с примерами и так далее
Поделитесь своими идеями в комментариях, какие еще видите подходы?
Может быть у нас вместе получится собрать несложный фреймворк/экосистему с конкретными материалами, но сначала нужно определить базис, а это как раз и есть различные подходы.
В таких условиях выглядит так, что лучше тактикой будет стараться сократить необходимость использования поисковых систем, тут подходов много и все они затратные, но все же:
1. Максимально вкладываться в образование (в широком смысле). Часто из-за высокой загрзуки на это остается мало времени, а именно это дает возможность сократить множество нерешаемых задач
2. Формировать внутренние и внешние сообщества, где вбросил вопрос и кто-то может знать конкретный вектор поиска ответа или ответ
3. Развивать практические навыки на различных хакатонах и за счет прототипирования, – теория без практики быстро выветривается из головы
4. Расширять кругозор на митапах и конференциях, – здесь как раз идеи того, что можно попробовать сделать на практике; важно то, что вы знаете с кем можно обсудить проблему детальнее, этот человек буквально перед вами
5. Отдавать предпочтение книгам, – все-таки долгое погружение в один контекст дает лучший эффект, чем сотня разрозненных статей. Статьи пишут те, кто читает книги 🙂 Это я, конечно, упростил, но, скорее всего, именно книги помогут чаще находить ответы самостоятельно, потому что они развивают мысль, а статьи все ж чаще дают конкретный ответ, без более широго контекста, подводки, рассуждений, выводов с примерами и так далее
Поделитесь своими идеями в комментариях, какие еще видите подходы?
Может быть у нас вместе получится собрать несложный фреймворк/экосистему с конкретными материалами, но сначала нужно определить базис, а это как раз и есть различные подходы.
Традиционно для подписчиков канала скидка на archdays.ru 20% и на онлайн и на оффлайн по промокоду microservices_arch
В этом году большой конкурс и чтобы никого не расстраивать, с теми, кто согласился, мы провели и проведем еще митапы (два уже запланировано, скоро анонсы), а спикеров митапов ArchDays Meetup мы приглашаем бесплатно на конференцию, так что их можно будет найти пообщаться 🙂
В этом году большой конкурс и чтобы никого не расстраивать, с теми, кто согласился, мы провели и проведем еще митапы (два уже запланировано, скоро анонсы), а спикеров митапов ArchDays Meetup мы приглашаем бесплатно на конференцию, так что их можно будет найти пообщаться 🙂