Остается несколько часов до завершения регистрации на очное посещение DDD-meetup. Места пока еще позволяют. Ссылка на регистрацию:

https://docs.google.com/forms/d/e/1FAIpQLSc-6DZAndwQNFIu-rDBwe3YRJKfunrBTIpiBHeoY0wB36DsdQ/viewform

Еще один сборник практик применения DDD в Golang.

- https://mehdihadeli.github.io/awesome-go-education/ddd/
- https://mehdihadeli.github.io/awesome-go-education/cqrs/

Ничего особенного, просто очередной признак того, что тренд набирает обороты.

#Golang #DDD #CQRS #EventSourcing

На вчерашней встрече ко мне возникло два вопроса.

Я говорил ранее, что хотелось бы заложить традицию "прорабатывать вопросы до конца".
- https://news.1rj.ru/str/emacsway_log/749

Поэтому, отвечаю на вопросы.

Вопрос первый касался асимтоты при обсуждении графика роста стоимости изменения кода (адаптации).

В оригинале фраза звучит так:

"What would we do if all that investment paid off? What if all that work on languages and databases and whatnot actually got somewhere? What if the cost of change didn't rise exponentially overtime, but rose much more slowly, eventually reaching an asymptote? What if tomorrow's software engineering professor draws Figure 3 on the board?"
-- "Chapter 5. Cost of Change", "Extreme Programming Explained" 1st edition by Kent Beck

График, о котором идет речь на Figure 3, можно посмотреть здесь:
- https://emacsway.github.io/_images/asymptotic-cost-of-change.png

Что такое асимтота, можно посмотреть в "§284 Асимтоты" Справочника по высшей математике / М.Я. Выгодский:

"Прямая АВ называется асимптотой линии L, если расстояние МК (черт. 297) от точки М линии L до прямой АВ стремится к нулю при удалении точки М в бесконечность."

В нашем случае, нас интересуют Асимптоты, параллельные оси абсцисс (там же):

"Для разыскания горизонтальных асимптот линии y = f(х) ищем пределы f(х) при х -> +∞ и при х -> -∞. Если lim х->∞ f(x) = b, то прямая у = b - асимптота (при бесконечном удалении вправо; черт. 299)."

Здесь приводится полная цитата Kent Beck о том, что только пологий график (стремящийся к горизонтальной асимтоте) делает итеративную разработку (в данном случае - в виде XP) возможной:
- https://news.1rj.ru/str/emacsway_log/151

"The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work."

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

Второй вопрос был по поводу итеративной разработки.

Краткая история развития итеративной разработки от Craig Larman:
- https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf

Назначение итеративной разработки - разрешение неопределенности требований опытным (эмпирическим) путем:
- https://news.1rj.ru/str/emacsway_log/497
- https://news.1rj.ru/str/emacsway_log/498

#Agile #SDLC #Management #SoftwareArchitecture

Как-то я упустил из внимания тот факт, что первая offline-встреча DDD-сообщества после пандемии состоялась 22 декабря, т.е. сразу после зимнего солнцестояния.

В старину говорили, что в этот день свет начинает брать верх над тьмой (над ночью). Это символично совпало с названием одной из наиболее популярных статей уходящего года "о темных веках разработки":
- https://threedots.tech/post/software-dark-ages/
, которую перевел @gradea :
- https://habr.com/ru/company/cian/blog/569940/

Интересно, что Великая Отечественная война началась в день летнего солнцестояния (когда тьма начинает брать верх над светом), а Г.К.Рокоссовский, командовавший Парадом Победы 24 июня 1945 года на Красной площади в Москве, родился 21 декабря, в день зимнего солнцестояния.

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

Запись первого offline DDD-meetup после пандемии:

- https://youtu.be/ybYtgII151g?t=27m10s

Было здорово! После митапа выпили пива в дружеской обстановке. Вживую познакомился с грамотными и перспективными ребятами, образующими костяк сообщества. Удивила высокая слаженность и взаимопонимание с полуслова, хотя со многими виделся впервые. В разведку с ними пошел бы.

Для себя я вынес пару новых книг по коммуникативной психологии и прекрасное лаконичное определение сути Agile от Kent Beck всего в 9 слов, которое на вес золота (скоро опубликую). Синхронизировался с крутыми специалистами архитектурного авангарда - авторами книг, известными паблик-спикерами и организаторами архитектурных конференций, ведущими курсов по архитектуре ПО, практикующими архитекторами известных высоконагруженных проектов, и понял, что развиваюсь в правильном направлении и исследую нужные вопросы. Заодно узнал, какой вкусный шашлык готовят в кафе, расположенном в БЦ Академик.

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

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

Немного о картах ограниченных контекстов (bounded context map).

Один из способов выразить карту ограниченных контекстов средствами Archi смотрите на диаграмме "Views : Tactical Architecture : Program Level : Context Map" этой модели для Archi:
- https://community.opengroup.org/archimate-user-community/home/-/issues/8

Там же: EventStorming и C4 Model

"Context Map Cheat Sheet" by Nick Tune:
- https://github.com/ddd-crew/ddd-starter-modelling-process#organise
- https://github.com/ddd-crew/context-mapping
- https://github.com/ddd-crew/context-mapping-quiz
- https://miro.com/app/board/o9J_lzWf14U=/
- https://miro.com/app/board/o9J_kqrI8ck=/

- https://contextmapper.org/
- https://github.com/ContextMapper

- https://domorobo.to/

"Visualizing sociotechnical architectures with Context Maps"
- https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps?slide=56

#DDD #Microservices #SoftwareArchitecture

Булева алгебра множеств. Шпаргалка. Математика.
- https://news.1rj.ru/str/Pomatematike/645

The Art of Discovering Bounded Contexts by Nick Tune
- https://www.youtube.com/watch?v=ez9GWESKG4I

#DDD #Microservices #SoftwareArchitecture

Два новых перевода от хабраюзера ArkadiyXIII на статьи Vladik Khononov (@vladik_kh):

"Преодоление сложности в CQRS"
- https://habr.com/ru/post/588803/

"Распутывание микросервисов или балансировка сложности в распределенных системах"
- https://habr.com/ru/post/590165/

Последняя статья является монументальной и имеет критическое значение для тех, кто работает с микросервисами. Из нее вы поймете, чем же отличается микросервис от Bounded Context, и почему изначальное утверждение Sam Newman в первом издании своей книги о том, что это одно и то же, уже утратило актуальность.

#DDD #SoftwareArchitecture #SoftwareDesign #CQRS #Microservices

📝 "A Bounded Context is not a purely logical (language consistency, unity of purpose) or physical (code separation, deployment unit) concept. It's an obligation to maintain integrity between those views."

-- Alberto Brandolini https://twitter.com/ziobrando/status/1476471050565259267?t=Otw4mDHJXA5zcX2623AFNw&s=19

#DDD #SoftwareDesign #SoftwareArchitecture

Друзья, разрешите поздравить вас всех с наступающим Новым Годом, и пожелать в новом году ярких побед и высоких достижений!

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

Количество подписчиков канала существенно возрасло, и я хочу поблагодарить вас за оказанное доверие.

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

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

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

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

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

Вместе с тем, мне видится четко сформулированной повестка и наступающего года. Я заметил, что участники сообщества, обладая чрезвычайной грамотностью технических решений, зачастую имеют потребность в решении проблем не технических, а человеческих - что делать, когда продакт не выделяет ресурсов на рефакторинг легаси, или в команде возникает сопротивление и зарождается раскол. Что делать, когда не получается побороть инертную машину, опутывающую эффективность разработчика. Вот где взаимовыручка сообщества приходит на помощь - даже я вынес для себя невероятно ценную информацию. В будущем году хотелось бы провести ряд встреч, посвященных вопросам построения грамотных и эффективных процессов, распределения обязанностей, управленческой и коммуникативной психологии. Хочется приобщиться к той цели, которой Kent Beck посвятил всю свою карьеру: "My career mission is to help geeks feel safe in the world."

Спасибо вам всем!

Новых высоких достижений в Новом Году! Высокой ясности новых знаний! Здоровья и благополучия вам и вашим близким!

По поводу "нам некогда писать качественный код". Добавил в dckms свой сборник высказываний авторитетных авторов о том, как качество кода влияет на темпы разработки:
- https://dckms.github.io/system-architecture/emacsway/it/sdlc/uncertainty-management/adaptation/software-design/software-design.html

Этот сборник служит больше для цели повлиять на кого-то, задавить весом авторитета. Мне он когда-то хорошо помогал. Когда "влиять" не нужно, а нужно уже "делать", то есть другая статья о том, как писать экономически эффективный код:
- https://dckms.github.io/system-architecture/emacsway/it/sdlc/uncertainty-management/adaptation/crash-course-in-software-development-economics.html

Из личного опыта: когда я еще писал код, то на одном из последних моих проектов в роли программиста, я в одиночку закрывал стори-поинтов в три раза больше, чем два других программиста вместе взятые, и это при том, что мой код был канонически правильным. Т.е. примерно в шесть раз быстрее. Не верьте тем, кто говорит "некогда писать правильный код".

Кстати, когда я сам такое говорил (было дело) на заре своей карьеры, и к нам пришел новый, опытный разработчик, то он в одиночку делал в два раза больше, чем у нас делала команда из трех человек (тоже примерно в шесть раз быстрее). Собственно, именно так я впервые и познакомился с XP и с Clean Code - от практики.

#Career #SoftwareDesign #Agile

Domain Storytelling Modeler:
- https://www.wps.de/modeler/

Исходники:
- https://github.com/WPS/domain-story-modeler

#DDD #SoftwareDesign #SoftwareArchitecture #EventStorming #DomainStorytelling

Eще один источник еженедельных обзоров по архитектуре:
- https://twitter.com/deararchitects

- https://www.deararchitects.xyz/

Thanks to Anton Zhilin ( @zhant )

#SoftwareArchitecture

📝 "Ты — господин несказанного слова, а сказанного слова — ты слуга." — Омар Хайям

P.S.: не мог не поделиться 🙂))

#SoftSkills #Career

Начну вот с этой ссылки https://unfix.work/ Все уже хором принялись ругать эту… - не мышонка, не лягушку, а Not Another Agile Scaling Framework.

А оно ведь свеженькое (первое сообщение в блоге https://unfix.work/blog от 2 января), с картинками в виде диаграмм Эйлера, как мы любим :-) (кстати, пакет картинок можно скачать за регистрацию) и историями про экипажи, возвращающиеся на базу… Базы бывают разные, экипажи тоже. И всё это великолепие кружится в инновационном вихре.

Из FAQ: The unFIX model is more a modeling tool than a framework. In fact, you can use the tool to define frameworks such as SAFe, LeSS, and Holacracy, which you can all create out of the elements of unfix

Так что ругать здесь особо нечего. Инструмент он и есть инструмент