Поиск решения на основе схожести проблемы обретает популярность не только в архитектуре (https://www.tgoop.com/archicases , https://bytebytego.com/ ), но и в OSINT:
- https://osint-mindset.gitbook.io/cases/dom-kotoryi

На конкретных примерах приводятся решения по обнаружению геолокации фотографии и др.

🔷 "Counter-OSINT: руководство по приватности и защите своих данных в Сети"

Я и не знал, что так можно:
https://github.com/archimatetool/archi/issues/265#issuecomment-447963893

Всегда делал заменой в текстовых файлах:
https://github.com/archi-contribs/archi-grafico-plugin/wiki/GRAFICO-explained

[UPDATE]: Итоговый результат здесь:
https://github.com/archimatetool/archi/issues/663#issuecomment-674039925

Часто говорят, что вот как формировать Bounded Context - еще более-менее понятно, а вот как выявлять Subdomain?

💬 Domains are synonymous with business capabilities from the business architecture world.
-- "Architecture Ownership Patterns For Team Topologies. Part 1: A Business Architecture Model" by Nick Tune

💬 The Enterprise Architecture world uses the concept of Business Capabilities at different levels. Business Capabilities can be viewed as domains and subdomains.
-- "Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined" by Nick Tune

💬 A subdomain is a subpart of a domain, and specifically applicable within Scope 3. It’s often the case that a subdomain is the same as a business capability.
-- "Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture" by Vaughn Vernon

Дальше все по TOGAF с помощью Archimate.

[UPDATE]: See also "Product & Domain-Oriented Business Architecture Building Blocks"

#DDD

💬 How to Identify Sub-Domains

Domain knowledge is key to decomposing a domain into sub-domains that have a high level of internal cohesion and minimum dependencies with other sub-domains. Conducting an event storming workshop is a great way to accelerate the acquisition of domain knowledge and explore domain decomposition scenarios.

-- OA-Standard, chapter "20.1.1. Domains and Sub-Domains"
https://pubs.opengroup.org/architecture/o-aa-standard/DDD-strategic-patterns.html#KLP-DDD-sub-domains

Говорят, что молодые специалисты сейчас мало читают, но много смотрят видео.

Скажу честно, я видео не смотрю почти никогда, за редким исключением.

Причин несколько.

1. Низкая скорость усвоения информации. Чтение банально быстрее примерно на порядок.

2. Низкое качество информации. Степень продуманности, дистилляции и структуризации письменной информации все-таки выше. Меньше воды. Именно по этой причине мало кто любит "голосовухи в телеге".

3. Мне не нужно слушать все подряд. Мне нужно выделить только релевантную информацию и проскочить нерелевантную. Чтение облегчает это.

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

5. Письменную информацию легче конспектировать в электронном блокноте или делать пометки в читалке.

6. https://dckms.github.io/system-architecture/emacsway/soft-skills/learning.html

7. https://dckms.github.io/system-architecture/README.html#id11

Кто-то красиво сказал, что люди делятся на две категории: на тех, кто читает, и на тех, кто слушает тех, кто читает.

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

Перевод оригинальной статьи Ron Jeffries о Story Point:
- "Обдумывая стори поинты"

Ценнейшая информация. Напомню, что он считается их изобретателем.

О приоритезации грамотным языком. Картинка в статье бесценна.
- "Определите свои классы обслуживания с помощью Триаж Таблиц"

Пообщался со @schetinnikov . Выяснилось, что он имеет преподавательский опыт и неплохие спикерские навыки. Глубоко знает проблематику DDD и умеет интересно вести дискуссию. Дискуссия настолько получилась увлекательной, что я предложил проводить подобные дискуссии на регулярной основе более широким кругом.

Кто за - пишите в комментариях (ибо лайки анонимны) 🙂

Так вот откуда эта повальная тяга к говнокоду, когда каждый спринт производится по системному инкременту экскременту. Спасибо друзьям, разъяснили:
https://dzen.ru/a/X4QlsEKmlnP3zjoN

Даже самые выдающиеся авторы обсуждают эту тему на конференциях мирового масштаба:
https://www.tgoop.com/ru_arc_chat/14208

[UPDATE]: Рекорд цены за 30 грамм отходов жизнедеятельности Пьеро Мандзони был поставлен в мае 2008 года на аукциона Sotheby's – банка №83 была продана с молотка за 97250 фунтов стерлингов. Получается, что сегодня дерьмо художника почти в 100 раз дороже золота.

Часто спрашивают, как сделать так, чтоб изменение вступило в силу в нужный момент времени. По разным причинам. Например, нужно обработать много данных, но чтоб результат стал видим единовременно.

Новая статья Kent Beck как раз об этом:
🔷 "Eventual Business Consistency"

См. также:

🔷 https://martinfowler.com/eaaDev/timeNarrative.html
🔷 https://martinfowler.com/eaaDev/TemporalObject.html
🔷 https://martinfowler.com/eaaDev/TemporalProperty.html
🔷 https://martinfowler.com/eaaDev/Effectivity.html
🔷 https://martinfowler.com/eaaDev/Snapshot.html

Есть идея. Допустим, вы являетесь успешным специалистом, и хотите освоить новый аспект знаний, например, EventStorming.

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

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

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

И этот курс будет создавать вам имя и укреплять карьерные перспективы.

Кому было бы интересно, поставьте 👍, пожалуйста. Интересно оценить осуществимость идеи.

Еще одна идея. Вернее, две, но обо всем по порядку.

Я в последний месяц смог позволить себе появиться в тг-групах. Вопросы задают все те же, и ответы на них те же. Я дал несколько ответов, которые мне самому показались интересными. Из-за дефицита времени иногда приходилось отвечать устно, например, https://www.tgoop.com/iDDDqd/21557 .

К сожалению, личные обстоятельства не позволяют мне оформить мою же информацию и опубликовать в электронном блокноте.

Вы знаете, что у меня есть блокнот, состоящий из приватной, корпоративной и публичной частей. Публичная часть доступна здесь:
https://dckms.github.io/system-architecture/

Алфавитный указатель:
https://dckms.github.io/system-architecture/genindex.html

Этот блокнот имеет несколько особенностей:

1. Как вы знаете, в Zettelkasten используется тегирование вместо рубрикации потому, что узел древовидного дерева рубрикатора не может принадлежать нескольким родителям. В моем блокноте на sphinx-doc это возможно, что позволяет организовать многопользовательскую среду, в которой у каждого из авторов есть свое собственное дерево навигации, в которое он может вставлять статьи и поддеревья из деревьев навигации других авторов. Также можно создавать общее, главное дерево навигации. В общем, перекрестные деревья - невероятно мощный механизм, который незаслуженно недооценнен.

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

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

Подробнее о других возможностях см. здесь:
https://dckms.github.io/system-architecture/README.html#id13

Полное описание:
https://dckms.github.io/system-architecture/README.html

Возникший дефицит времени вынуждает меня искать новые формы решений. Возникает идея.

Любой может задать мне вопрос в канале этого чата:
https://www.tgoop.com/emacsway_chat

Мой ответ может быть полным или неполным, например, "посмотрите в книге такой-то по словам таким-то". Может быть устным, а может быть письменным.

Автор вопроса прорабатывает ответ и оформляет полученный инкремент знаний в отчуждаемом виде в коллективно-распределенном электронном блокноте
https://github.com/dckms/system-architecture/
под моим наставничеством и рецензированием.

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

А оформление знаний в структурированном виде в электронном блокноте является невероятно мощным способом информационной навигации. Вы знаете, что главный бич нашей индустрии - это синдром "коллекционера знаний", когда информация накапливается в бесполезную свалку, лишенную возможности навигации в ней.

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

Наиболее хороший материал будет включаться в главное навигационное дерево блокнота.

Что думаете по этому поводу? Кто готов принять участие, поставьте, пожалуйста, 👍, чтоб я смог оценить жизнеспособность идеи.

В идеале хотелось бы сформировать стабильный коллектив.

Также нужны помощники по переносу материалов этого канала в блокнот, например,
- https://www.tgoop.com/emacsway_log/1113
- https://www.tgoop.com/emacsway_log/1074
и др. Если кто-то готов подключиться к процессу, пишите мне в приват @emacsway или в чат канала @emacsway_chat .

Вторую идею напишу позже.

Да, кстати, эта идея ни в коем случае не заменяет предыдущую.

🔷 "Как выбрать коммерческие курсы, обучающие ИТ-профессии" / Денис Бесков

«Архитектура – это равновесие,
мастер – это тот, кто умеет привести силы природы в равновесие,
мастерство – это умение привести силы природы в равновесие,
творчество – это желание привести силы природы в равновесие»

https://cyberleninka.ru/article/n/kontsept-masterstva-i-mastera-v-arhitekture

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

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

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

💬 "Лидеры умеют чередовать глобус с микроскопом. Они мыслят масштабно, но избирательно уходят в детали, когда рассматривают ключевые моменты."

Подсмотрено здесь:
https://www.tgoop.com/ClubM/1447

Не могу не согласиться. Мой опыт и мой анализ деятельности великих исторических деятелей это подтверждает.

Ответ на вопрос о том, должен ли архитектор уметь погружаться в код, тоже зависит, как мне кажется, от того, хочет ли он быть лидером или просто рисовать диаграммы:
https://youtu.be/31qcPwAv8Zw

Великолепная статья от Kent Beck для тех компаний, которые трекают активности своих разработчиков:
https://tidyfirst.substack.com/p/measuring-developer-productivity-440