Более подробно познакомился с DDD. В основе там онтологическая инженерия, но без использования слов "онтика" и "онтология". При этом в наличии все основные ошибки программистов (тут я сужу по книжке "Learning Domain-Driven Design", октябрь 2021, https://b-ok.cc/book/17873719/83aeaf). В тексте постоянно путаются domain и bounded context: то они в реальности, то описывают реальность, то это вообще софт, то это про разное, то одно и то же. В итоге приходят к тому, что работать нужно с практиками, отслеживать состояние альф, альфы делать предметами кейсов, и далее даются рекомендации, как это всё разносить по разным командам разработки так, чтобы они не мешали друг другу. Фишка в том, что все говорят об одном и том же, причём в абсолютно разной терминологии, и с разными неразличениями в понятийной структуре. А мне надо излагать как-то "беспредметно". Очень хочется сделать табличку соответствия (и не одну) для разных практик инженерии в части используемых понятий. Проблема в том, какой набор понятий использовать, можно ведь и DDD взять за основу, но можно и текущий набор понятий из "Практического системного мышления" и "Методологии". Я буду, конечно, брать понятия из "Практического системного мышления" и "Методологии", и не столько из-за того, что они там нейтральны к предметным областям, сколько из-за того, что они там все работают с понятием системы и хоть как-то онтологически выверены (при всей кривизне понятия "альфа").
Итого в кровавом энтерпрайзе (это программная инженерия корпоративных приложений) получается, что (и это всё не слишком расходится для from scratch и brownfield):
-- разработчики и архитекторы занимаются онтологической инженерией, начиная с "интересных событий" (Event Storm), потихоньку восстанавливая альфы, с которыми происходят эти события, и восстанавливая цепочки этих событий (case template).
-- далее архитекторы по-крупному определяют модульную структуру и интерфейсы, принимая архитектурные решения исходя из архитектурных интересов (книжки на эту тему я уже давал во втором абзаце тут: https://ailev.livejournal.com/1639178.html), пытаясь попасть куда-то в sweet spot между Big Ball of Mud (большой спутанный плотный клубок) и Distributed Big Ball of Mud (плотно запутанное множество крошечных аккуратных клубков)
-- можно ещё выделить безопасников, но их часто включают в DevSecOps (но не всегда)
-- и иногда ещё включают спецов по общей организации разработки (кто-то ведь должен за всем этим списком следить, "чтобы все не переругались в продуктивных конфликтах"), methods and culture. Но это тоже опционально.
-- DevOps делают инфраструктуру, в которой всё это будет потом continuous интегрироваться и выпускаться для пользователей, причём там может быть множество самых разных команд.
-- далее разработчики (среди которых на этом уровне рассмотрения не видно подролей, но это cross-functional team, в которой практически все традиционные роли, начиная с инженера по требованиям aka "аналитик", только вместо архитектора "проектировщик", а вместо DevOp тестировщик) пишут код, испытывая при этом governance со стороны всех, кто был помянут выше (а DevOps считают для всех них метрики, чтобы мягко объяснять разработчикам, как им работать, вот про архитектурные метрики свеженькое, Software Architecture Metrics, 2022 (это Early Release), https://b-ok.cc/book/21916214/b6e3a7).
У меня собралось довольно много уже заметок по софтовым практикам как минимум кровавого энтерпрайза (что важно, ибо дальше будет системный менеджмент), и с завтрашнего дня начну разбираться с ML/DL и "железными" (хотя ещё хочу внимательней поглядеть на свеженькие разговоры про DevOps и SRE, там ведь тоже идут довольно быстрые подвижки в связи с прошедшей за последний пяток лет тотальной контейнеризацией и переходом на SaaS).
А ещё у меня руки чешутся обновлять и "Практическое системное мышление" с "Методологией", но я себе этого не даю. Надо завершить полный круг -- системная инженерия, системный менеджмент, ОдО и МОО. И только потом идти на второй круг.
В квантовом компьютинге существенный прорыв: при комнатной температуре за шесть минут на системе EQC решена задача оптимального размещения сенсоров на автомобиле (это BMW Sensor Challenge, problem scale 3584 переменных и 501 ограничение): https://www.youtube.com/watch?v=GANYTiyW9Qk (вот тут текстом и с какими-то ссылками, но без картинок: https://www.tomshardware.com/news/quantum-computing-company-solves-3854-variable-problem-for-bmw-in-six-minutes). Это улучшение результата прошлого года x70 (прошлогодний challenge выиграла эта же фирма на компьютере D-Wave, а тот они прикупили фирму с оригинальным хардвером, работающим на альтернативных принципах).
В биологии тоже интересно: DeepMind выложила для 0.5млн биологов (вау, сколько на свете биологов!) базу структур 200 млн. белков, практически всё, что можно найти в живых организмах на планете (и, как я понимаю, ещё и кое-что, чего нельзя найти в живых организмах, но такого немного, а всего там сейчас представлен 1 млн видов в этой базе данных), https://www.deepmind.com/blog/alphafold-reveals-the-structure-of-the-protein-universe. По сравнению с предыдущим релизом AlphaFold DB это x200 по количеству.
Очень мне эти x70 и x200 нравятся. "Подрывы" (disruptions) по Тони Себа начинаются, если что-то удаётся сделать x10 дешевле при прежних характеристиках, или x10 по характеристикам при прежней цене. Это всё экспоненты, когда ничего-ничего-ничего, и потом ВНЕЗАПНО -- ой, что это нас окружает?!
Мой оптимизм по отсутствию мирового апокалипсиса где бы то ни было на планете как раз базируется на вот этих прорывах. Даже в самых бедных странах при таких темпах развития техники станет жить лучше, хотя до них докатятся не все эти x10 и x100 из развитых стран (того самого "золотого миллиарда", который сегодня в российской прессе и блогосфере любят называть "не вся планета"), а x2 и x3 для стран недоразвитых -- но и это будет огромный прогресс! За час труда еды и воды будет вдвое больше, а если свезёт, то они будут ещё и вдвое лучше!
Бесплатная улучшалка старых фотографий: https://app.baseten.co/apps/QPp4nPE/operator_views/RqgOnqV. Вот тут я-студент на старом химфаке в центре Ростова-на-Дону, это где-то 1976 год:
