Короче, я психанул и создал канал про цифровизацию образования: https://t.iss.one/nodxhere
Это две вещи, которые меня особенно волнуют:
* Как наиболее эффективно создавать программные системы (отсюда — системный анализ, проектирование и управление продуктом, весь канал, который вы читаете);
* Как наиболее эффективно учить людей.
И вот в последнем, мне кажется, глупо не использовать цифровые технологии — уж если они радикально меняют и перестраивают другие области жизни, то уж образование тоже должны! Но мы видим странное — вроде, и технологии внедряются, и деньги выделяются, и рынок растет — а принципиальных изменений как не было, так и нет. Не происходит подрыва, как в других отраслях. Даже на горизонте не видно. Уже автономные автомобили по улицам ездят, а мы всё так же слушаем лекции, как в Древней Греции, и пишем эссе, как в XVI веке.
В общем, кажется, что-то где-то идёт не так, и интересно — что именно.
И многие исследования показывают, что цифровизация-то образования происходит, а какой-то принципиальной трансформации — нет. Поэтому и канал я так и назвал: "Цифровизация без трансформации"
В общем, если вам интересна тема образования и технологий, милости прошу:
https://t.iss.one/nodxhere
Там будет много ссылок на разные исследования, в основном школьного и вузовского образования — просто потому, что их больше исследуют и они образуют системы, в отличие от профессионального и неформального ("наплодились всякие курсы"). Ну и мои наблюдения — всё-таки, я уже почти 20 лет преподаю, 10 лет занимаюсь проектированием и созданием систем в этой области, кое-что видел и, смею надеяться, понял.
Это две вещи, которые меня особенно волнуют:
* Как наиболее эффективно создавать программные системы (отсюда — системный анализ, проектирование и управление продуктом, весь канал, который вы читаете);
* Как наиболее эффективно учить людей.
И вот в последнем, мне кажется, глупо не использовать цифровые технологии — уж если они радикально меняют и перестраивают другие области жизни, то уж образование тоже должны! Но мы видим странное — вроде, и технологии внедряются, и деньги выделяются, и рынок растет — а принципиальных изменений как не было, так и нет. Не происходит подрыва, как в других отраслях. Даже на горизонте не видно. Уже автономные автомобили по улицам ездят, а мы всё так же слушаем лекции, как в Древней Греции, и пишем эссе, как в XVI веке.
В общем, кажется, что-то где-то идёт не так, и интересно — что именно.
И многие исследования показывают, что цифровизация-то образования происходит, а какой-то принципиальной трансформации — нет. Поэтому и канал я так и назвал: "Цифровизация без трансформации"
В общем, если вам интересна тема образования и технологий, милости прошу:
https://t.iss.one/nodxhere
Там будет много ссылок на разные исследования, в основном школьного и вузовского образования — просто потому, что их больше исследуют и они образуют системы, в отличие от профессионального и неформального ("наплодились всякие курсы"). Ну и мои наблюдения — всё-таки, я уже почти 20 лет преподаю, 10 лет занимаюсь проектированием и созданием систем в этой области, кое-что видел и, смею надеяться, понял.
Telegram
Цифровизация без трансформации
Как происходит цифровая трансформация образования? Что работает, а что нет? И как это измерить?
Мировые исследования и авторский взгляд Юрия Куприянова @YuryKupriyanov
Мировые исследования и авторский взгляд Юрия Куприянова @YuryKupriyanov
👍15❤4🔥2
Сергей Баранов написал про DDD — Domain Driven Design. Предметно-ориентированное проектирование, как его по-русски называют.
У меня есть по поводу DDD несколько инсайтов, накопилось материала на отдельный пост.
1) Аналитики не особо знают DDD, потому что DDD придумано как раз для ситуаций, когда разработчики работают без аналитиков. И нужно как-то понять, что там эти пользователи вообще хотят. А ничего нет — ни моделей процессов, ни требований, ни модели данных. Интересно тут то, что, в принципе, подошла бы любая техника выявления требований и описания предметной области: хоть модели БП, хоть Use Cases, хоть User Story Mapping. Было бы желание. Но желания в этом разбираться у программистов как раз обычно и нет, интереснее же писать код. То, что написанный код очень отдаленно соответствует предметной области, решает локальные проблемы и закрывает возможности для развития — выясняется сильно позже и больно бьет. Поэтому программисты придумали свой метод — запишем ровно то, что говорят пользователи (ubiquitous language), и будем делать в программе классы именно с такими именами — тогда произойдет магия и нас не заругают.
2) Программистам больше всего интересен слой логики. Вопрос хранения данных решает ORM, вопрос проектирования интерфейсов вообще оскорбителен — это дело дизайнеров же. Поэтому юскейсы и user story не заходят — они слишком много говорят о пользователях и сценариях их работы. Нам бы что-нибудь поближе к классам и их взаимодействию. То есть, это всё то же решение задачи — какие именно классы создать в объектно-ориентированной программе. Есть паттерны GoF, но они слишком низкоуровневые. Есть юскейсы — но они слишком высокуровневые, и непонятно, как перейти от них к классам. Знания предков, типа подхода Якобсона к отображению юскейсов на классы через Entity Object - Control Object - Boundary Object, оказались прочно забыты.
Кроме того, программисты склонны упрощать юскейсы до операций CRUD, начисто отбрасывая всё рассмотрение деятельности пользователей (какая ещё деятельность, нипанятна). В Clean Architecture каждый use case — это отдельный класс, и они все живут в своем отдельном слое юскейсов. Вроде бы это как раз пересказ идей Якобсона про Control Object, но понятый не всеми. При этом часть логики живет в этом слое, а часть в Entity — опять непонятно, несмотря на название. DDD вводит свою терминологию (агрегаты, инварианты), и мы попадаем в ситуацию, когда несколько подходов говорят об одном и том же, но разными словами.
3) DDD упирает на generic domains: типовые домены, для которых вообще не нужно ничего разрабатывать, а взять готовое. Называются оценки 80/20 или даже 95/5 — мол, в вашем решении уникального-то всего 5%, на них и сосредоточьтесь, а остальное возьмите готовое.
Здесь нужно быть втройне аккуратными, т.к. есть большой риск "выплеснуть с водой ребенка". Generic могут быть только низкоуровневые компоненты, типа аутентификации, хранения файлов, отрисовки интерфейсов и математических операций, или стандартизованные бизнес-функции, типа платежей, электронной подписи или обмена сообщениями.
Всё, что несет чуть больше бизнесового контекста, попадает под два закона:
1. "Парадокс переиспользования": степень эффективности выполнения задачи компонентом в конкретном контексте обратно пропорциональна возможности переиспользования этого компонента (чем лучше работает, тем хуже возможность переиспользовать);
2. "Эффект фастфуда": чуть хуже + чуть хуже + чуть хуже + ... = полный провал. Если мы возьмем "95% не уникальных Generic функций", которые всего лишь чуть хуже, чем специализированные — на выходе получим неудобоваримое нечто.
Поэтому мы не видим массово никаких "generic" библиотек или сервисов для бизнес-функций. Всё, что у нас есть — универсальные фреймворки, низкоуровневые библиотеки и готовые сервисы с типовой функциональностью. Может, вас и устроит типовое решение, но, как правило, лишь до какого-то момента.
Итого, три инсайта про DDD: это для программистов без аналитиков, это для слоя логики, и со склонностью применять упрощенные решения там. А так-то дело хорошее.
У меня есть по поводу DDD несколько инсайтов, накопилось материала на отдельный пост.
1) Аналитики не особо знают DDD, потому что DDD придумано как раз для ситуаций, когда разработчики работают без аналитиков. И нужно как-то понять, что там эти пользователи вообще хотят. А ничего нет — ни моделей процессов, ни требований, ни модели данных. Интересно тут то, что, в принципе, подошла бы любая техника выявления требований и описания предметной области: хоть модели БП, хоть Use Cases, хоть User Story Mapping. Было бы желание. Но желания в этом разбираться у программистов как раз обычно и нет, интереснее же писать код. То, что написанный код очень отдаленно соответствует предметной области, решает локальные проблемы и закрывает возможности для развития — выясняется сильно позже и больно бьет. Поэтому программисты придумали свой метод — запишем ровно то, что говорят пользователи (ubiquitous language), и будем делать в программе классы именно с такими именами — тогда произойдет магия и нас не заругают.
2) Программистам больше всего интересен слой логики. Вопрос хранения данных решает ORM, вопрос проектирования интерфейсов вообще оскорбителен — это дело дизайнеров же. Поэтому юскейсы и user story не заходят — они слишком много говорят о пользователях и сценариях их работы. Нам бы что-нибудь поближе к классам и их взаимодействию. То есть, это всё то же решение задачи — какие именно классы создать в объектно-ориентированной программе. Есть паттерны GoF, но они слишком низкоуровневые. Есть юскейсы — но они слишком высокуровневые, и непонятно, как перейти от них к классам. Знания предков, типа подхода Якобсона к отображению юскейсов на классы через Entity Object - Control Object - Boundary Object, оказались прочно забыты.
Кроме того, программисты склонны упрощать юскейсы до операций CRUD, начисто отбрасывая всё рассмотрение деятельности пользователей (какая ещё деятельность, нипанятна). В Clean Architecture каждый use case — это отдельный класс, и они все живут в своем отдельном слое юскейсов. Вроде бы это как раз пересказ идей Якобсона про Control Object, но понятый не всеми. При этом часть логики живет в этом слое, а часть в Entity — опять непонятно, несмотря на название. DDD вводит свою терминологию (агрегаты, инварианты), и мы попадаем в ситуацию, когда несколько подходов говорят об одном и том же, но разными словами.
3) DDD упирает на generic domains: типовые домены, для которых вообще не нужно ничего разрабатывать, а взять готовое. Называются оценки 80/20 или даже 95/5 — мол, в вашем решении уникального-то всего 5%, на них и сосредоточьтесь, а остальное возьмите готовое.
Здесь нужно быть втройне аккуратными, т.к. есть большой риск "выплеснуть с водой ребенка". Generic могут быть только низкоуровневые компоненты, типа аутентификации, хранения файлов, отрисовки интерфейсов и математических операций, или стандартизованные бизнес-функции, типа платежей, электронной подписи или обмена сообщениями.
Всё, что несет чуть больше бизнесового контекста, попадает под два закона:
1. "Парадокс переиспользования": степень эффективности выполнения задачи компонентом в конкретном контексте обратно пропорциональна возможности переиспользования этого компонента (чем лучше работает, тем хуже возможность переиспользовать);
2. "Эффект фастфуда": чуть хуже + чуть хуже + чуть хуже + ... = полный провал. Если мы возьмем "95% не уникальных Generic функций", которые всего лишь чуть хуже, чем специализированные — на выходе получим неудобоваримое нечто.
Поэтому мы не видим массово никаких "generic" библиотек или сервисов для бизнес-функций. Всё, что у нас есть — универсальные фреймворки, низкоуровневые библиотеки и готовые сервисы с типовой функциональностью. Может, вас и устроит типовое решение, но, как правило, лишь до какого-то момента.
Итого, три инсайта про DDD: это для программистов без аналитиков, это для слоя логики, и со склонностью применять упрощенные решения там. А так-то дело хорошее.
👍19😁7❤5🤔1
Forwarded from Блог Сергея Баранова (Сергей Баранов)
Продолжение про «похожие процессы» и про важность DDD.
(кажется, получился очень глубокий и важный пост про важность DDD)
Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс…
Взять сферу туризма – это отдельная профессия, ей учатся по пять лет, чтобы нормально разбираться в маршрутах, сезонах, рисках, партнерах и ожиданиях клиентов. И взять разработчика – тоже лет пять только чтобы уверенно писать код, понимать архитектуру, паттерны, инфраструктуру.
И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает.
В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать».
Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без….
У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу.
Потом еще одну.
Потом «быструю доработку к сезону».
Потом срочный костыль «потому что партнер меняет правила».
Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой
И вот в системе сотня мест, где бизнес-жвачка намотана на технический долг и любая попытка рефакторинга превращается в операцию на сердце.
С должным усилием, упорством и желанием этот разработчик вырастает до архитектора.
Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic.
Вот эту проблему во многом и решает DDD вместе с практиками вроде Event Storming.
Они как раз про то, как вытащить знание экспертов (в нашем примере – гуру в туризме), перевести его в общий язык и донести до разработчиков и архитекторов так, чтобы все видели одну и ту же цельную картину.
Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.
(кажется, получился очень глубокий и важный пост про важность DDD)
Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс…
Взять сферу туризма – это отдельная профессия, ей учатся по пять лет, чтобы нормально разбираться в маршрутах, сезонах, рисках, партнерах и ожиданиях клиентов. И взять разработчика – тоже лет пять только чтобы уверенно писать код, понимать архитектуру, паттерны, инфраструктуру.
И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает.
В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать».
Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без….
У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу.
Потом еще одну.
Потом «быструю доработку к сезону».
Потом срочный костыль «потому что партнер меняет правила».
Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой
И вот в системе сотня мест, где бизнес-жвачка намотана на технический долг и любая попытка рефакторинга превращается в операцию на сердце.
С должным усилием, упорством и желанием этот разработчик вырастает до архитектора.
Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic.
Вот эту проблему во многом и решает DDD вместе с практиками вроде Event Storming.
Они как раз про то, как вытащить знание экспертов (в нашем примере – гуру в туризме), перевести его в общий язык и донести до разработчиков и архитекторов так, чтобы все видели одну и ту же цельную картину.
Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.
🔥18💯2
В комментариях опять пишут про взвешенный анализ характеристик. Ну что ж, эта тема тоже имеет место, правда, обычно не в IT. Вообще про измерения качества чего угодно (какого-то продукта) есть много теорий.
И вот эти красивые картинки — из метода QFD, Quality Function Deployment. А сама картинка называется "Дом качества". Придуман он, конечно, японцем — Йодзи Акао (Yoji Akao) и, конечно, в 60-е годы. И, разумеется, среди ит-шников мало известен, хотя этот метод — часть движения бережливого производства.
"Дом качества" изначально связывает пользовательские и инженерные характеристики (что важно пользователю и как можно произвести продукт), но тут можно связать функциональные (что?) и нефункциональные (как?), или, например, атрибуты внешнего качества (что?) и архитектурные решения (как?). А можно зарядить в него метрики продукта (что?) и фичи из бэклога (как?).
QFD учитывает приоритет свойств, силу связей между однотипными свойствами продукта и её знак — усиление или снижение (те самые tradeoffs, или противоречия): ++, +, [](нет связи), -, —. Заодно он расставляет веса свойств. Причем, чтобы не спорить — в чем тонкая разница между 0.2 и 0.3, предлагается всего три значения: 1,3,9 (ещё 0 - свойство не важно, но такие свойства и не появляются в оценке).
Дальше на пересечении строится матрица зависимостей: какое "как?" как влияет на какое "что?". В результате получаются взвешенные оценки каждого свойства, по сути — профиль решения. Его можно сравнить с конкурентами. А снизу приписать техническую возможность и сложность (стоимость) реализации.
Вот так можно всю систему на одной картинке визуализировать с приоритетами, профилями и направлениями улучшений.
Делали когда-нибудь такой анализ для своих продуктов?
И вот эти красивые картинки — из метода QFD, Quality Function Deployment. А сама картинка называется "Дом качества". Придуман он, конечно, японцем — Йодзи Акао (Yoji Akao) и, конечно, в 60-е годы. И, разумеется, среди ит-шников мало известен, хотя этот метод — часть движения бережливого производства.
"Дом качества" изначально связывает пользовательские и инженерные характеристики (что важно пользователю и как можно произвести продукт), но тут можно связать функциональные (что?) и нефункциональные (как?), или, например, атрибуты внешнего качества (что?) и архитектурные решения (как?). А можно зарядить в него метрики продукта (что?) и фичи из бэклога (как?).
QFD учитывает приоритет свойств, силу связей между однотипными свойствами продукта и её знак — усиление или снижение (те самые tradeoffs, или противоречия): ++, +, [](нет связи), -, —. Заодно он расставляет веса свойств. Причем, чтобы не спорить — в чем тонкая разница между 0.2 и 0.3, предлагается всего три значения: 1,3,9 (ещё 0 - свойство не важно, но такие свойства и не появляются в оценке).
Дальше на пересечении строится матрица зависимостей: какое "как?" как влияет на какое "что?". В результате получаются взвешенные оценки каждого свойства, по сути — профиль решения. Его можно сравнить с конкурентами. А снизу приписать техническую возможность и сложность (стоимость) реализации.
Вот так можно всю систему на одной картинке визуализировать с приоритетами, профилями и направлениями улучшений.
Делали когда-нибудь такой анализ для своих продуктов?
🤯10🔥6❤4😍2
Ну и завершая тему DDD (готов уворачиваться от помидоров) — ни в одной рекламной статье вам не расскажут про "DDD трилемму" — аналог CAP-теоремы для моделирования доменов.
Из-за этого разработчики и архитекторы, столкнувшись на практике с, скажем аккуратно, неудобствами реализации DDD на тактическом уровне в реальных проектах, приходят в группы и чаты по DDD, и там их начинают возить мордой об стол и тыкать в книги основоположников.
Дело в том, что из трёх китов: изоляции доменной логики, чистоты модели и производительности можно выбрать, как обычно, только два пункта.
В реальной жизни у вас либо бизнес-логика оказывается размазана по уровням (что-то контролируется в модели, что-то — в контроллере, что-то вообще в БД), либо модель должна ходить в базу / в глубинные слои инфраструктуры, соответственно — начинает зависеть от реализации, либо всё красиво и абстрактно, но нещадно тормозит.
Вот ключевая статья на эту тему от Владимира Хорикова https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/ + преза на русском.
Там простой пример: проверка уникальности email'а при регистрации пользователя. Как его делать? То ли передать с уровня домена в контроллер (и там сначала проверить существование пользователя с таким email), то ли прямо из модели пользователя сходить в хранилище поискать email'ы, то ли поднимать всех пользователей из хранилища на уровень домена, и отдавать модели пользователя (сожрет всю память).
Ну и вот, выбирайте, как хотите. И так, и так, и так будет криво, вопрос — с какой кривизной вы готовы столкнуться?
Это, в общем, следствие старого Закона дырявых абстракций Джоела Спольски: все нетривиальные абстракции дырявы.
И DDD тут тоже не является серебряной пулей. Собственно, претензии к адептам примерно те же, что и к инфобизнесменам — не в том дело, что приемы какие-то неправильные, дело в том, что нельзя создавать впечатление, что DDD решит все проблемы с целостностью и изолированностью изменений. Не решит. Всё равно придётся выбирать плохое из худшего.
Из-за этого разработчики и архитекторы, столкнувшись на практике с, скажем аккуратно, неудобствами реализации DDD на тактическом уровне в реальных проектах, приходят в группы и чаты по DDD, и там их начинают возить мордой об стол и тыкать в книги основоположников.
Дело в том, что из трёх китов: изоляции доменной логики, чистоты модели и производительности можно выбрать, как обычно, только два пункта.
В реальной жизни у вас либо бизнес-логика оказывается размазана по уровням (что-то контролируется в модели, что-то — в контроллере, что-то вообще в БД), либо модель должна ходить в базу / в глубинные слои инфраструктуры, соответственно — начинает зависеть от реализации, либо всё красиво и абстрактно, но нещадно тормозит.
Вот ключевая статья на эту тему от Владимира Хорикова https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/ + преза на русском.
Там простой пример: проверка уникальности email'а при регистрации пользователя. Как его делать? То ли передать с уровня домена в контроллер (и там сначала проверить существование пользователя с таким email), то ли прямо из модели пользователя сходить в хранилище поискать email'ы, то ли поднимать всех пользователей из хранилища на уровень домена, и отдавать модели пользователя (сожрет всю память).
Ну и вот, выбирайте, как хотите. И так, и так, и так будет криво, вопрос — с какой кривизной вы готовы столкнуться?
Это, в общем, следствие старого Закона дырявых абстракций Джоела Спольски: все нетривиальные абстракции дырявы.
И DDD тут тоже не является серебряной пулей. Собственно, претензии к адептам примерно те же, что и к инфобизнесменам — не в том дело, что приемы какие-то неправильные, дело в том, что нельзя создавать впечатление, что DDD решит все проблемы с целостностью и изолированностью изменений. Не решит. Всё равно придётся выбирать плохое из худшего.
👍12🤔3❤2🔥1💯1
"Назови три"
Я с большим подозрением отношусь ко всему, что напоминает секту — от методологов до приверженцев DDD, с их специфическими выдуманными терминами, безапелляционной риторикой, жесткой критикой не принадлежащих к их тусовке и убеждением, что они знают о мире что-то секретное и дающее тайную власть.
Но у всех них, однако, можно чему-то научиться. Вот, например, попалась мне статья с LessWrong, а потом и вторая. LessWrong — это главный ресурс движения рационалистов. Ну, теорема Байеса, борьба с когнитивными искажениями, "Гарри Поттер и методы рационального мышления", вот это всё.
Статья про конкретику (в английском, как обычно, есть два отдельных слова: specific и concreteness). Я думаю, мы все с этим сталкиваемся, когда говорим с заказчиками. Да и когда между собой спорим, что уж тут.
Вы спрашиваете про функции будущей системы, а заказчик вам начинает говорить что-то про "эффективное решение для организации коммуникации между подразделениями" или "оптимальное распределение состава финансовых инструментов в портфеле". И вроде всё понятно, но что конкретно делать-то?
В статье приводят в пример разбор дейтинг-стартапа на школе YCombinator: на вопрос, а что конкретно лучше он делает по сравнению с обычными способами общения, автор отвечает нечто вроде "конкретно наш продукт предоставляет более лучший способ коммуникации для людей, они много что делают в реальной жизни, и пытаются это делать онлайн, и мы даем им онлайн-инструмент, чтобы делать это". Понятно, в чем фишка стартапа?
То же самое постоянно делают участники тренингов: вместо того, чтобы быть конкретными, стараются наоборот обобщать. Так в документах и на диаграммах появляются "данные клиента", "информация о товаре", "контент курса" и "управление скидками".
В обсуждениях постоянно появляются участники, стремящиеся добиться четких определений. Нет, давайте договоримся — что мы называем моделью, а что — представлением. (К чести сказать, в обсуждениях к постам в этом канале эта болезнь редко встречается). Это путь по лестнице абстракций вверх, то есть — в никуда. Каждое новое определение и обобщение на самом деле не помогает пониманию. Пониманию помогает движение в другую сторону — к конкретике. Не играйте в слова определений, приведите пример, а лучше несколько.
В изучении иностранных языков есть такая игра: "назови три". Тебе дают общее понятие, и нужно назвать три конкретных. Три предмета одежды, три кухонных прибора, три водоплавающих птицы и т.д. Очень полезное упражнение, им можно и собеседников на интервью возвращать к конкретике. Приведите пример, пожалуйста. Ладно, не три, хотя бы один. Хотя лучше несколько — для разных ситуаций.
Помню, каким шоком для меня было определение понятия "мощность множества". "Это то, что одинаково у равномощных множеств". А что, так можно было? То есть, мы не будем давать определения через другие понятия? Просто возьмем для примера несколько равномощных множеств, и то, что у них одинаковое — это и будем называть "мощностью"? Ну, то есть, "красный цвет" — это то, что одинаково у пожарной машины и сигнала светофора, на который нужно остановиться на перекрестке? Это по крайней мере, понятно.
Я раньше не мог понять, что заставляет людей возноситься к абстрактным понятиям. LessWrong утверждает, что это когнитивное искажение, связанное с экономией мыслетоплива и подстановкой атрибута — назвать абстрактное (всё объясняющее) понятие проще, чем подумать над конкретным примером. LW предлагают ловить это у себя: как только заметили слишком абстрактные слова или мысли — остановитесь и придумайте конкретный пример. Но для нас, как аналитиков, очень важно вытаскивать конкретику из других людей, поэтому и на собеседниках нужно использовать этот прием, просить привести примеры — типичные и исключительные.
Из конкретных примеров проще собрать обобщенную картину, чем наоборот — от абстракции перейти к деталям. Потому что названное абстрактное слово вас ограничивает в представлении от том, что возможно; а разброс реальных кейсов — наоборот, заставляет учесть даже то, что не лезет в общее понятие.
Я с большим подозрением отношусь ко всему, что напоминает секту — от методологов до приверженцев DDD, с их специфическими выдуманными терминами, безапелляционной риторикой, жесткой критикой не принадлежащих к их тусовке и убеждением, что они знают о мире что-то секретное и дающее тайную власть.
Но у всех них, однако, можно чему-то научиться. Вот, например, попалась мне статья с LessWrong, а потом и вторая. LessWrong — это главный ресурс движения рационалистов. Ну, теорема Байеса, борьба с когнитивными искажениями, "Гарри Поттер и методы рационального мышления", вот это всё.
Статья про конкретику (в английском, как обычно, есть два отдельных слова: specific и concreteness). Я думаю, мы все с этим сталкиваемся, когда говорим с заказчиками. Да и когда между собой спорим, что уж тут.
Вы спрашиваете про функции будущей системы, а заказчик вам начинает говорить что-то про "эффективное решение для организации коммуникации между подразделениями" или "оптимальное распределение состава финансовых инструментов в портфеле". И вроде всё понятно, но что конкретно делать-то?
В статье приводят в пример разбор дейтинг-стартапа на школе YCombinator: на вопрос, а что конкретно лучше он делает по сравнению с обычными способами общения, автор отвечает нечто вроде "конкретно наш продукт предоставляет более лучший способ коммуникации для людей, они много что делают в реальной жизни, и пытаются это делать онлайн, и мы даем им онлайн-инструмент, чтобы делать это". Понятно, в чем фишка стартапа?
То же самое постоянно делают участники тренингов: вместо того, чтобы быть конкретными, стараются наоборот обобщать. Так в документах и на диаграммах появляются "данные клиента", "информация о товаре", "контент курса" и "управление скидками".
В обсуждениях постоянно появляются участники, стремящиеся добиться четких определений. Нет, давайте договоримся — что мы называем моделью, а что — представлением. (К чести сказать, в обсуждениях к постам в этом канале эта болезнь редко встречается). Это путь по лестнице абстракций вверх, то есть — в никуда. Каждое новое определение и обобщение на самом деле не помогает пониманию. Пониманию помогает движение в другую сторону — к конкретике. Не играйте в слова определений, приведите пример, а лучше несколько.
В изучении иностранных языков есть такая игра: "назови три". Тебе дают общее понятие, и нужно назвать три конкретных. Три предмета одежды, три кухонных прибора, три водоплавающих птицы и т.д. Очень полезное упражнение, им можно и собеседников на интервью возвращать к конкретике. Приведите пример, пожалуйста. Ладно, не три, хотя бы один. Хотя лучше несколько — для разных ситуаций.
Помню, каким шоком для меня было определение понятия "мощность множества". "Это то, что одинаково у равномощных множеств". А что, так можно было? То есть, мы не будем давать определения через другие понятия? Просто возьмем для примера несколько равномощных множеств, и то, что у них одинаковое — это и будем называть "мощностью"? Ну, то есть, "красный цвет" — это то, что одинаково у пожарной машины и сигнала светофора, на который нужно остановиться на перекрестке? Это по крайней мере, понятно.
Я раньше не мог понять, что заставляет людей возноситься к абстрактным понятиям. LessWrong утверждает, что это когнитивное искажение, связанное с экономией мыслетоплива и подстановкой атрибута — назвать абстрактное (всё объясняющее) понятие проще, чем подумать над конкретным примером. LW предлагают ловить это у себя: как только заметили слишком абстрактные слова или мысли — остановитесь и придумайте конкретный пример. Но для нас, как аналитиков, очень важно вытаскивать конкретику из других людей, поэтому и на собеседниках нужно использовать этот прием, просить привести примеры — типичные и исключительные.
Из конкретных примеров проще собрать обобщенную картину, чем наоборот — от абстракции перейти к деталям. Потому что названное абстрактное слово вас ограничивает в представлении от том, что возможно; а разброс реальных кейсов — наоборот, заставляет учесть даже то, что не лезет в общее понятие.
🔥20💯8❤4👍3👎2
— У нас протечка.
— Протечка чего?
— У меня всё сиденье мокрое.
— Должно быть, это абстракции протекли.
К дискуссии о границах ролей. Кажется, границы ролей должны проходить по границам абстракций. Пока тебе не нужно думать о том, как это на самом деле работает — ты остаешься в рамках одной роли.
В институте нас очень аккуратно провели по всем уровням абстракций при создании электронной аппаратуры:
Сначала ты анализируешь задачу — твоё устройство вообще зачем? Какие функции оно будет выполнять?
Потом строишь алгоритм, или, например, карту Карно. Или целую функциональную схему (для цифровых схем — логическую), где только нолики и единички бегают.
Потом — принципиальную электрическую, и тут выясняется, что постоянный ток не очень-то постоянный, нолики не совсем нолики, а единички — совсем не единички, и что при нажатии кнопки бывает дребезг контактов, который может вызвать 3-5 ложных срабатываний. Причем обрабатывать это нужно либо на логическом уровне, либо вообще на программном — а вот вам и протечка абстракции!
Потом нужно развести плату (и расположение элементов на ней может сильно отличаться от принципиальной схемы!), а потом внезапно выясняется, что значки на принципиальной схеме на самом деле имеют размер, высоту, они греются, пылятся, трескаются на холоде, испускают электромагнитное излучение, а ещё имеют собственную частоту (и ваша плата может треснуть, войдя в резонанс при размещении, например, на автомобиле), при пайке их нельзя перегревать, а при креплении платы винтами — перетягивать.
Кое-что из этого можно и нужно решать программно — например, нагрев. Опять протечка!
И эти протечки нам могут подсказать границы ролей. Если в бизнес-процессе участвует смежная система — какое у аналитика предположение о её ответе? Она всегда доступна и отвечает мгновенно? Это бизнес-анализ. Ответ занимает столько-то миллисекунд в 95% случаев? При получении ответа 500 мы ждем 3 секунды и пытаемся выполнить запрос повторно? Это системный анализ/проектирование. Что мы показываем пользователю во время этого ожидания, чтобы он не нажал ещё несколько раз, не видя отклика? Это протечка абстракции: мы должны учесть детали реализации. В устранении протечки должны участвовать две роли. Перекладывать на бизнес-аналитика задачу "представить себе, как это будет реализовано" — это с больной головы на здоровую, не его зона ответственности, не его уровень абстракции. Мы же стараемся, чтобы более верхний уровень не знал о деталях реализации нижележащего.
Можно попробовать ещё накидать типовых точек протечек:
— Поиск/фильтрация по большому объему данных. А вы об индексах подумали? А может, запретим выдачу без фильтров, а то слишком много результатов, это full scan — протечка! Мы не должны думать об устройстве базы. Нужна совместная работа двух ролей. Сюда же — пагинация, поэтому её так часто БА забывают.
— Форматы данных при передаче. JSON? XML? Avro?
— Парадигма хранилища (реляционное, колоночное, документарное)
— Домены данных в хранилище (типы + ограничения на формат/диапазон, а вот бизнес-правила — это уже уровень выше)
— Кэширование, управление кэшированием (это и для системного аналитика часто вне рассмотрения)
— Распределение обращений по однотипным узлам, балансировка нагрузки
— Стратегии обеспечения согласованности, CAP/PACELC, уровни согласованности данных
— Развертывание, обновление
— Поддержка разных окружений (браузеры, ОС, оборудование, подключение к сети)
Разборки со всеми этими уровнями требуют двух точек зрения:
1. Взгляд на устройство системы: а почему я не могу сделать систему такой, чтобы об этом не нужно было думать?
2. Взгляд на внешние проявления системы: если система будет так себя вести, какую сигнализацию я бы хотел видеть, и какие дополнительные действия мне нужны (например — прерывание зависшей операции, локальное сохранение черновиков, принудительная синхронизация)
В конечном итоге, кажется, всё это укладывается в проверочный вопрос "если системы нет, то как это будет исполняться?" Пока нет конкретной реализации системы — это бизнес-анализ, нужно учитывать особенности реализации — системный.
— Протечка чего?
— У меня всё сиденье мокрое.
— Должно быть, это абстракции протекли.
К дискуссии о границах ролей. Кажется, границы ролей должны проходить по границам абстракций. Пока тебе не нужно думать о том, как это на самом деле работает — ты остаешься в рамках одной роли.
В институте нас очень аккуратно провели по всем уровням абстракций при создании электронной аппаратуры:
Сначала ты анализируешь задачу — твоё устройство вообще зачем? Какие функции оно будет выполнять?
Потом строишь алгоритм, или, например, карту Карно. Или целую функциональную схему (для цифровых схем — логическую), где только нолики и единички бегают.
Потом — принципиальную электрическую, и тут выясняется, что постоянный ток не очень-то постоянный, нолики не совсем нолики, а единички — совсем не единички, и что при нажатии кнопки бывает дребезг контактов, который может вызвать 3-5 ложных срабатываний. Причем обрабатывать это нужно либо на логическом уровне, либо вообще на программном — а вот вам и протечка абстракции!
Потом нужно развести плату (и расположение элементов на ней может сильно отличаться от принципиальной схемы!), а потом внезапно выясняется, что значки на принципиальной схеме на самом деле имеют размер, высоту, они греются, пылятся, трескаются на холоде, испускают электромагнитное излучение, а ещё имеют собственную частоту (и ваша плата может треснуть, войдя в резонанс при размещении, например, на автомобиле), при пайке их нельзя перегревать, а при креплении платы винтами — перетягивать.
Кое-что из этого можно и нужно решать программно — например, нагрев. Опять протечка!
И эти протечки нам могут подсказать границы ролей. Если в бизнес-процессе участвует смежная система — какое у аналитика предположение о её ответе? Она всегда доступна и отвечает мгновенно? Это бизнес-анализ. Ответ занимает столько-то миллисекунд в 95% случаев? При получении ответа 500 мы ждем 3 секунды и пытаемся выполнить запрос повторно? Это системный анализ/проектирование. Что мы показываем пользователю во время этого ожидания, чтобы он не нажал ещё несколько раз, не видя отклика? Это протечка абстракции: мы должны учесть детали реализации. В устранении протечки должны участвовать две роли. Перекладывать на бизнес-аналитика задачу "представить себе, как это будет реализовано" — это с больной головы на здоровую, не его зона ответственности, не его уровень абстракции. Мы же стараемся, чтобы более верхний уровень не знал о деталях реализации нижележащего.
Можно попробовать ещё накидать типовых точек протечек:
— Поиск/фильтрация по большому объему данных. А вы об индексах подумали? А может, запретим выдачу без фильтров, а то слишком много результатов, это full scan — протечка! Мы не должны думать об устройстве базы. Нужна совместная работа двух ролей. Сюда же — пагинация, поэтому её так часто БА забывают.
— Форматы данных при передаче. JSON? XML? Avro?
— Парадигма хранилища (реляционное, колоночное, документарное)
— Домены данных в хранилище (типы + ограничения на формат/диапазон, а вот бизнес-правила — это уже уровень выше)
— Кэширование, управление кэшированием (это и для системного аналитика часто вне рассмотрения)
— Распределение обращений по однотипным узлам, балансировка нагрузки
— Стратегии обеспечения согласованности, CAP/PACELC, уровни согласованности данных
— Развертывание, обновление
— Поддержка разных окружений (браузеры, ОС, оборудование, подключение к сети)
Разборки со всеми этими уровнями требуют двух точек зрения:
1. Взгляд на устройство системы: а почему я не могу сделать систему такой, чтобы об этом не нужно было думать?
2. Взгляд на внешние проявления системы: если система будет так себя вести, какую сигнализацию я бы хотел видеть, и какие дополнительные действия мне нужны (например — прерывание зависшей операции, локальное сохранение черновиков, принудительная синхронизация)
В конечном итоге, кажется, всё это укладывается в проверочный вопрос "если системы нет, то как это будет исполняться?" Пока нет конкретной реализации системы — это бизнес-анализ, нужно учитывать особенности реализации — системный.
❤14👍4
Я тут вместе с ChatGPT немного подумал про разделение ролей и протечку абстракций, и вот что у нас получилось, полюбопытствуйте:
Абстракции есть не только в архитектуре. Роли на уровне организации распределены тоже по слоям абстракций, с обещанием "вам на этом уровне не нужно об этом думать". Это [само]обман — абстракции всегда дырявы. С этим не нужно бороться, это нужно учитывать.
Частая ошибка — проводить границы ролей по артефактам ("кто описывает процессы, кто требования, а кто API"). Артефакт — след деятельности, а не её смысл. А граница проходит по языку, точнее — по модальностям. Сергей Нужненко любит упоминать логику, ну вот всё проектирование — это набор модальных логик, своих для каждой роли. По сути, описание разных миров с операторами достижимости: □ "во всех достижимых мирах" / ◊ "в некотором достижимом мире".
По ролям эти логики раскладываются так:
Продакт (владелец ценности). Модальность пользы: "желательно/целесообразно/вероятно окупится | во всех мирах/в отдельном мире". Это логика предпочтений и неопределённости. "В большинстве релевантных сценариев это даёт пользу [и это лучше, чем другой вариант], мы твердо уверены в этом".
BA (владелец политик). Деонтическая модальность, логика норм и обязательств: обязательно/разрешено/запрещено. "Во всех допустимых (нормативно корректных) вариантах поведения бизнеса это должно быть так".
SA (владелец модели). Динамическая и темпоральная модальность: "после события X", "всегда", "в состоянии системы S1 | допустимо/обязательно". Сюда же модальность последовательности ("после выполнения действия A допустимо/обязательно B"). В общем, это про целостность, "во всех достижимых состояниях модели инварианты сохраняются".
Архитектор, владелец качества. Мультимодальность достижимости гарантий во всех режимах/при сбоях/нагрузке. Это гарантии, но не логические/бизнесовые, а технические, низкоуровневые. "В реальных условиях запрошенный уровень гарантий требует пересмотра".
Разработчик, владелец реализации. В теории, должен действовать в логике формальных методов (TLA+, лямбда-исчисление, конечные автоматы и т.п.), но в реальности всё это слишком сложно, поэтому никакой логике действия разработчика не поддаются.
Абстракции дырявы, поэтому области интереса пересекаются и оказывают влияние друг на друга: на уровень ценности всплывают юридические ограничения и стоимость качества; на уровень инвариантов — ограничения согласованности в распределенных системах; на уровень качества — дырки в наблюдаемости и эмерджентность слабосвязанных событий. Поэтому всем нужно регулярно со всеми разговаривать и договариваться.
ИИ предлагает регулярные ритуалы для выявления взаимовлияний — по-моему, он их просто на ходу придумал, цитирую без правки:
Feature framing (PM ведёт): гипотеза ценности + ограничения + метрика + допустимые компромиссы по качеству.
Policy workshop (BA ведёт): правила + исключения + спорные кейсы + "кто имеет право решать исключения в рантайме".
Model review (SA ведёт): сущности/состояния/события + инварианты + контракты интеграций + миграции.
Quality attribute workshop (архитектор ведёт): сценарии качества (нагрузка, отказ, атака) + бюджеты (latency/cost) + деградации.
Design/operability review (dev ведёт): стратегия тестирования + наблюдаемость + откаты + SLO-реальность.
А роли, в конечном итоге — это предохранители необратимых потерь. Вот смотрите, что можно необратимо потерять:
— данные, если не собирали, то уже и не соберем; если необратимо испортили — обратно не восстановим (SA)
— деньги — из-за атак или сбоев (архитектор, ИБ) или неверного расчета экономики (продакт)
— доверие рынка / право на деятельность (продакт, BA)
— возможности развития (архитектор, разработчик)
Вот такая раскладка, что думаете?
Ну и это про роли, их можно совмещать, пока в одну голову влезает и друг друга не тормозит. А внедрять нужно не "в процессы" и не "передавая задачи", а назначая зоны ответственности за необратимость.
Абстракции есть не только в архитектуре. Роли на уровне организации распределены тоже по слоям абстракций, с обещанием "вам на этом уровне не нужно об этом думать". Это [само]обман — абстракции всегда дырявы. С этим не нужно бороться, это нужно учитывать.
Частая ошибка — проводить границы ролей по артефактам ("кто описывает процессы, кто требования, а кто API"). Артефакт — след деятельности, а не её смысл. А граница проходит по языку, точнее — по модальностям. Сергей Нужненко любит упоминать логику, ну вот всё проектирование — это набор модальных логик, своих для каждой роли. По сути, описание разных миров с операторами достижимости: □ "во всех достижимых мирах" / ◊ "в некотором достижимом мире".
По ролям эти логики раскладываются так:
Продакт (владелец ценности). Модальность пользы: "желательно/целесообразно/вероятно окупится | во всех мирах/в отдельном мире". Это логика предпочтений и неопределённости. "В большинстве релевантных сценариев это даёт пользу [и это лучше, чем другой вариант], мы твердо уверены в этом".
BA (владелец политик). Деонтическая модальность, логика норм и обязательств: обязательно/разрешено/запрещено. "Во всех допустимых (нормативно корректных) вариантах поведения бизнеса это должно быть так".
SA (владелец модели). Динамическая и темпоральная модальность: "после события X", "всегда", "в состоянии системы S1 | допустимо/обязательно". Сюда же модальность последовательности ("после выполнения действия A допустимо/обязательно B"). В общем, это про целостность, "во всех достижимых состояниях модели инварианты сохраняются".
Архитектор, владелец качества. Мультимодальность достижимости гарантий во всех режимах/при сбоях/нагрузке. Это гарантии, но не логические/бизнесовые, а технические, низкоуровневые. "В реальных условиях запрошенный уровень гарантий требует пересмотра".
Разработчик, владелец реализации. В теории, должен действовать в логике формальных методов (TLA+, лямбда-исчисление, конечные автоматы и т.п.), но в реальности всё это слишком сложно, поэтому никакой логике действия разработчика не поддаются.
Абстракции дырявы, поэтому области интереса пересекаются и оказывают влияние друг на друга: на уровень ценности всплывают юридические ограничения и стоимость качества; на уровень инвариантов — ограничения согласованности в распределенных системах; на уровень качества — дырки в наблюдаемости и эмерджентность слабосвязанных событий. Поэтому всем нужно регулярно со всеми разговаривать и договариваться.
ИИ предлагает регулярные ритуалы для выявления взаимовлияний — по-моему, он их просто на ходу придумал, цитирую без правки:
Feature framing (PM ведёт): гипотеза ценности + ограничения + метрика + допустимые компромиссы по качеству.
Policy workshop (BA ведёт): правила + исключения + спорные кейсы + "кто имеет право решать исключения в рантайме".
Model review (SA ведёт): сущности/состояния/события + инварианты + контракты интеграций + миграции.
Quality attribute workshop (архитектор ведёт): сценарии качества (нагрузка, отказ, атака) + бюджеты (latency/cost) + деградации.
Design/operability review (dev ведёт): стратегия тестирования + наблюдаемость + откаты + SLO-реальность.
А роли, в конечном итоге — это предохранители необратимых потерь. Вот смотрите, что можно необратимо потерять:
— данные, если не собирали, то уже и не соберем; если необратимо испортили — обратно не восстановим (SA)
— деньги — из-за атак или сбоев (архитектор, ИБ) или неверного расчета экономики (продакт)
— доверие рынка / право на деятельность (продакт, BA)
— возможности развития (архитектор, разработчик)
Вот такая раскладка, что думаете?
Ну и это про роли, их можно совмещать, пока в одну голову влезает и друг друга не тормозит. А внедрять нужно не "в процессы" и не "передавая задачи", а назначая зоны ответственности за необратимость.
❤8🤔5👀3🔥2
Чем занимались системные аналитики 50 лет назад? Да тем же самым.
В одном из архитектурных чатов в очередной раз подвергается сомнению польза (и само существование) роли системного аналитика. Ну, архитекторы в своем репертуаре. Высказывалось даже предположение, что системный аналитик, как роль, появилась недавно и что-то там отобрала у архитекторов, какие-то функции.
Я не изучал историю архитекторов ПО, по некоторым публикациям, она появилась в 90-е годы в связи с демократизацией разработки, появлением библиотек, фреймворков и распространением клиент-серверной архитектуры.
Зато я исследовал историю профессии "системный аналитик", и даже писал про неё тут: https://t.iss.one/systemswing/284
Но архитекторы, конечно, говорят, что это не те аналитики, и занимались они совсем другим. Что ж, пришлось найти статью 1973 года JD Couger, 'Evolution of business system analysis techniques'. Эволюция техник анализа бизнес-систем! Эволюция, понимаете? 1973 год, это ещё методы структурного анализа только-только разрабатываются. Внутри там вообще сказка: он прослеживает истоки системного анализа до 1920-х, к Тейлору. Использование электронных машин — с 40-х. А 70-е — это уже третье поколение техник!
А вот чем занимались аналитики в 1970 годы:
Ну всё то же, чем мы занимаемся прямо сейчас, вплоть до проектирования интеграций! Ничего принципиально не поменялось за 55 лет (вот только архитекторы ещё появились).
Отдельно интересно, что там уже есть нечто вроде диаграмм BPMN (из 50-х годов!), смотрите какие они милые.
В одном из архитектурных чатов в очередной раз подвергается сомнению польза (и само существование) роли системного аналитика. Ну, архитекторы в своем репертуаре. Высказывалось даже предположение, что системный аналитик, как роль, появилась недавно и что-то там отобрала у архитекторов, какие-то функции.
Я не изучал историю архитекторов ПО, по некоторым публикациям, она появилась в 90-е годы в связи с демократизацией разработки, появлением библиотек, фреймворков и распространением клиент-серверной архитектуры.
Зато я исследовал историю профессии "системный аналитик", и даже писал про неё тут: https://t.iss.one/systemswing/284
Но архитекторы, конечно, говорят, что это не те аналитики, и занимались они совсем другим. Что ж, пришлось найти статью 1973 года JD Couger, 'Evolution of business system analysis techniques'. Эволюция техник анализа бизнес-систем! Эволюция, понимаете? 1973 год, это ещё методы структурного анализа только-только разрабатываются. Внутри там вообще сказка: он прослеживает истоки системного анализа до 1920-х, к Тейлору. Использование электронных машин — с 40-х. А 70-е — это уже третье поколение техник!
А вот чем занимались аналитики в 1970 годы:
Системный анализ заключается в сборе, организации и оценке информации о системе и среде, в которой она функционирует.
Цель системного анализа — изучить все аспекты системы: оборудование, персонал, условия эксплуатации, а также её внутренние и внешние требования — для создания основы для проектирования и внедрения более совершенной системы.
Понимание роли системного аналитика облегчается обращением к этапам цикла разработки системы. В данной статье выделяются семь этапов разработки системы:
Этап I — Документирование существующей системы
Этап II — Анализ системы для установления требований к улучшенной системе (логическое проектирование)
Этап III — Проектирование компьютеризированной системы (физическое проектирование)
Этап IV — Программирование и разработка процедур
Этап V — Реализация
Этап VI — Эксплуатация
Этап VII — Техническое обслуживание и модификация
Таким образом, системный анализ касается этапов I и II цикла разработки системы. Результатом системного анализа является логическая структура новой системы: спецификации входных и выходных данных системы, критерии принятия решений и правила обработки.
Современные системы сложны в разработке. В 1950-х годах компьютеризировались только подсистемы, например, система начисления заработной платы. Сегодня, в эпоху интегрированных систем, область применения систем многократно расширяется. [...]
Основным направлением усилий в области системного анализа и проектирования в 1970-х годах было горизонтальное и вертикальное расширение систем.
Расширение области применения и усложнение систем повышает сложность системного анализа и проектирования. Проектирование интеграций влечет за собой увеличение «начальных» затрат.
Ну всё то же, чем мы занимаемся прямо сейчас, вплоть до проектирования интеграций! Ничего принципиально не поменялось за 55 лет (вот только архитекторы ещё появились).
Отдельно интересно, что там уже есть нечто вроде диаграмм BPMN (из 50-х годов!), смотрите какие они милые.
❤25🔥23👍4🆒2
Если вам вдруг нечем заняться в зимний воскресный день, предлагаю задачку.
У программистов есть классическая, даже легендарная задача на собеседовании: FizzBuzz.
Нужно написать программу, которая для каждого числа от 1 до 100 выдает либо Fizz (если число делится без остатка на 3), либо Buzz (если число делится без остатка на 5), либо FizzBuzz, если число делится без остатка и на 3, и на 5. Если число не делится ни на 3, ни на 5 — нужно выдать само это число.
Задачу так часто давали разработчикам на интервью, что это стало уже анекдотом.
А решается она настолько просто, что появились разновидности с усложнением: FizzBuzz только с двумя if; FizzBuzz с двумя if без использования переменных; вообще без if и без переменных; без использования операции взятия остатка и т.д.
Есть решения невероятной сложности — например,
FizzBuzz на косинусах и дискретных преобразованиях Фурье: https://habr.com/ru/articles/969856/ (осторожно, в посте для вывода используется формула Эйлера комплексными числами, я вас предупредил), или
FizzBuzz на TensorFlow, на основе многослойного перцептрона со скрытым слоем: https://habr.com/ru/articles/301536/.
Впрочем, ближе к нам корпоративная реализация FizzBuzz: https://habr.com/ru/companies/contentai/articles/173885/ (язык — Java; 102 файла, разложенных по 44 папкам; используются такие ООП-паттерны, как Стратегия, Абстрактная фабрика, Декоратор, Адаптер; есть тесты). Впрочем, как пишут многие критики, до настоящего ПО корпоративного уровня этому решению далеко.
Вот я и предлагаю вам потренироваться — написать максимально полный набор требований к FizzBuzz. Что там должно быть? Что упускают все авторы? Давайте покажем этим программистам, что на самом деле они постоянно не учитывают в своих решениях!
У программистов есть классическая, даже легендарная задача на собеседовании: FizzBuzz.
Нужно написать программу, которая для каждого числа от 1 до 100 выдает либо Fizz (если число делится без остатка на 3), либо Buzz (если число делится без остатка на 5), либо FizzBuzz, если число делится без остатка и на 3, и на 5. Если число не делится ни на 3, ни на 5 — нужно выдать само это число.
Задачу так часто давали разработчикам на интервью, что это стало уже анекдотом.
А решается она настолько просто, что появились разновидности с усложнением: FizzBuzz только с двумя if; FizzBuzz с двумя if без использования переменных; вообще без if и без переменных; без использования операции взятия остатка и т.д.
Есть решения невероятной сложности — например,
FizzBuzz на косинусах и дискретных преобразованиях Фурье: https://habr.com/ru/articles/969856/ (осторожно, в посте для вывода используется формула Эйлера комплексными числами, я вас предупредил), или
FizzBuzz на TensorFlow, на основе многослойного перцептрона со скрытым слоем: https://habr.com/ru/articles/301536/.
Впрочем, ближе к нам корпоративная реализация FizzBuzz: https://habr.com/ru/companies/contentai/articles/173885/ (язык — Java; 102 файла, разложенных по 44 папкам; используются такие ООП-паттерны, как Стратегия, Абстрактная фабрика, Декоратор, Адаптер; есть тесты). Впрочем, как пишут многие критики, до настоящего ПО корпоративного уровня этому решению далеко.
Вот я и предлагаю вам потренироваться — написать максимально полный набор требований к FizzBuzz. Что там должно быть? Что упускают все авторы? Давайте покажем этим программистам, что на самом деле они постоянно не учитывают в своих решениях!
😁12❤6🔥5🥰2🤯2
Обсуждение FizzBuzz напомнило про старую задачку на моделирование классов и взаимодействия: как замоделировать ситуацию "человек пьет кофе из кружки".
Очевидно, у нас будут классы "человек" и "кружка", и, например, уровень кофе в кружке. А вот про взаимодействие вопрос: где живет метод "пить"? Класс "человек" отправляет сообщение "пить(объем кофе)" классу "кружка" ( person->cup.drink(30) )? Или человек пьет, а кружка тогда что делает? ( person.drinkFrom(cup,30) )
Я не помню, у кого я видел обсуждение этой задачи. Но пока искал, нашел прекрасную статью Грегора Хопа (соавтора "Паттернов интеграции корпоративных приложений") с иллюстрацией синхронной и асинхронной интеграции на примере Starbucks.
Если вы помните, заказ в Starbucks принимают синхронно: вы не можете в процессе заказа и оплаты отойти на минуточку, а потом вернуться. Заказ и оплата выполняются в одном синхронном взаимодействии, даже если растягивается по времени.
А вот приготовление выполняется асинхронно:
— разные напитки требуют разного времени приготовления
— разное оборудование может быть использовано параллельно
— приготовление может вставать в очередь, когда оборудование занято
— заказы могут быть готовы не в той последовательности, в которой были сделаны
Почему так сделано? Для увеличения пропускной способности. Если у вас один человек принимает оплату, а потом сам готовит кофе — вы получаете кофе быстрее (ваш заказ взят в работу сразу же), но за вами копится очередь, и часть людей может уйти, не дождавшись. Асинхронность позволяет легко организовать горизонтальное масштабирование — можно увеличить число барист.
Тем не менее, транзакция закончена только когда клиент получил напиток. В нашей гибридной архитектуре — с синхронным и асинхронным взаимодействием — транзакция становится распределенной. Тут можно увидеть несколько паттернов:
— Идентификатор корреляции (Correlation ID), чтобы сопоставить приготовленный напиток и заказ. В Starbucks в качестве этого идентификатора используют имя клиента.
— Обработка исключений. Когда описывают "саги", всегда пишут про компенсирующие действия. Но Хоп пишет, что есть три варианта:
1. Списание. Если транзакция завершилась неудачей, мы просто ничего не делаем. А что уже сделали — выбрасываем (списываем). Возможно, механизм исправления ошибки будет стоить дороже. Иногда у нас просто нет другой возможности, а иногда это бизнес-решение: если клиент не забрал напиток, его через какое-то время нужно вылить.
2. Повторная попытка. Если в ходе транзакции возник технический сбой, а не нарушение бизнес-правила, можно попробовать повторить действие. Чтобы не заморачиваться, можно повторить все действия (но для этого у нас должны быть идемпотентные получатели, чтобы можно было безопасно повторить все запросы, начиная с первого). Если кофемашина сломалась, нужно повторить все действия на другой.
3. Компенсирующие действия — выполнение обратных операций. Если мы совсем не смогли приготовить кофе, придется вернуть деньги.
— Альтернатива — двухфазный коммит, когда кассир выступает координатором, и принимает оплату только после приготовления напитка. Это сильно задерживает выполнение транзакции, но зато система никогда не находится в несогласованном состоянии. В реальном мире это, например, счета эскроу.
Что ещё можно вспомнить? Если рассмотреть другие закусочные, то можно увидеть паттерн Claim Check — когда клиент получает не финальный (тяжелый) результат, а чек, с которым он приходит за заказом. Тогда идентификатор корреляции — номер заказа, который есть на чеке.
И, раз мы используем гибридный подход, можем увидеть и паттерны синхронных взаимодействий:
— если у кассира сломалась касса или клиент замешкался с оплатой, можно открыть вторую кассу и перенаправить ожидающих клиентов туда — это паттерн Circuit Breaker, размыкатель. Как вариант — перестает принимать заказы на определенный вид напитка, например, если сломался капучинатор.
Все паттерны взаимодействия пришли из реального мира, в конечном счете.
Очевидно, у нас будут классы "человек" и "кружка", и, например, уровень кофе в кружке. А вот про взаимодействие вопрос: где живет метод "пить"? Класс "человек" отправляет сообщение "пить(объем кофе)" классу "кружка" ( person->cup.drink(30) )? Или человек пьет, а кружка тогда что делает? ( person.drinkFrom(cup,30) )
Я не помню, у кого я видел обсуждение этой задачи. Но пока искал, нашел прекрасную статью Грегора Хопа (соавтора "Паттернов интеграции корпоративных приложений") с иллюстрацией синхронной и асинхронной интеграции на примере Starbucks.
Если вы помните, заказ в Starbucks принимают синхронно: вы не можете в процессе заказа и оплаты отойти на минуточку, а потом вернуться. Заказ и оплата выполняются в одном синхронном взаимодействии, даже если растягивается по времени.
А вот приготовление выполняется асинхронно:
— разные напитки требуют разного времени приготовления
— разное оборудование может быть использовано параллельно
— приготовление может вставать в очередь, когда оборудование занято
— заказы могут быть готовы не в той последовательности, в которой были сделаны
Почему так сделано? Для увеличения пропускной способности. Если у вас один человек принимает оплату, а потом сам готовит кофе — вы получаете кофе быстрее (ваш заказ взят в работу сразу же), но за вами копится очередь, и часть людей может уйти, не дождавшись. Асинхронность позволяет легко организовать горизонтальное масштабирование — можно увеличить число барист.
Тем не менее, транзакция закончена только когда клиент получил напиток. В нашей гибридной архитектуре — с синхронным и асинхронным взаимодействием — транзакция становится распределенной. Тут можно увидеть несколько паттернов:
— Идентификатор корреляции (Correlation ID), чтобы сопоставить приготовленный напиток и заказ. В Starbucks в качестве этого идентификатора используют имя клиента.
— Обработка исключений. Когда описывают "саги", всегда пишут про компенсирующие действия. Но Хоп пишет, что есть три варианта:
1. Списание. Если транзакция завершилась неудачей, мы просто ничего не делаем. А что уже сделали — выбрасываем (списываем). Возможно, механизм исправления ошибки будет стоить дороже. Иногда у нас просто нет другой возможности, а иногда это бизнес-решение: если клиент не забрал напиток, его через какое-то время нужно вылить.
2. Повторная попытка. Если в ходе транзакции возник технический сбой, а не нарушение бизнес-правила, можно попробовать повторить действие. Чтобы не заморачиваться, можно повторить все действия (но для этого у нас должны быть идемпотентные получатели, чтобы можно было безопасно повторить все запросы, начиная с первого). Если кофемашина сломалась, нужно повторить все действия на другой.
3. Компенсирующие действия — выполнение обратных операций. Если мы совсем не смогли приготовить кофе, придется вернуть деньги.
— Альтернатива — двухфазный коммит, когда кассир выступает координатором, и принимает оплату только после приготовления напитка. Это сильно задерживает выполнение транзакции, но зато система никогда не находится в несогласованном состоянии. В реальном мире это, например, счета эскроу.
Что ещё можно вспомнить? Если рассмотреть другие закусочные, то можно увидеть паттерн Claim Check — когда клиент получает не финальный (тяжелый) результат, а чек, с которым он приходит за заказом. Тогда идентификатор корреляции — номер заказа, который есть на чеке.
И, раз мы используем гибридный подход, можем увидеть и паттерны синхронных взаимодействий:
— если у кассира сломалась касса или клиент замешкался с оплатой, можно открыть вторую кассу и перенаправить ожидающих клиентов туда — это паттерн Circuit Breaker, размыкатель. Как вариант — перестает принимать заказы на определенный вид напитка, например, если сломался капучинатор.
Все паттерны взаимодействия пришли из реального мира, в конечном счете.
❤25🔥12👍3
Удивительно, но я никогда не видел хороших чеклистов для микросервисов, особенно для проверки — правильно ли они выделены, всё ли продумано.
Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два.
Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить?
Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики.
Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите:
1. Идентичность и ответственность
1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс».
1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.).
1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис
2. Границы и связи с другими сервисами
2.1. Для сервиса понятен список use-case’ов, в которых он:
— ведущий (владеет бизнес-логикой),
— участник (вызывается другим сервисом, реагирует на событие).
2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события.
2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми".
2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех.
3. Данные и инварианты
3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук).
3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться"
3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия)
3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных)
3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие).
3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории
3.7. Приняты решения по модели чтения (CQRS, Event Sourcing)
4. Контракты, схемы и API
4.1. Составлен список внешних операций:
— команды (изменяют состояние),
— запросы (чтение),
— доменные события (что сервис публикует).
4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API.
4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки:
— ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency),
— какие — технические,
— как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку).
4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем
4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка
4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности
5. Надёжность, производительность, наблюдаемость
5.1. Для ключевых операций определены SLO:
— латентность
— доступность
— процент ошибок
5.2. Поведение при отказах: понятно, что делает сервис:
— при падении зависимого сервиса,
— при перегрузке (ограничение, деградация, очереди),
— есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок
5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам
5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке
5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования
Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два.
Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить?
Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики.
Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите:
1. Идентичность и ответственность
1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс».
1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.).
1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис
2. Границы и связи с другими сервисами
2.1. Для сервиса понятен список use-case’ов, в которых он:
— ведущий (владеет бизнес-логикой),
— участник (вызывается другим сервисом, реагирует на событие).
2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события.
2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми".
2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех.
3. Данные и инварианты
3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук).
3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться"
3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия)
3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных)
3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие).
3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории
3.7. Приняты решения по модели чтения (CQRS, Event Sourcing)
4. Контракты, схемы и API
4.1. Составлен список внешних операций:
— команды (изменяют состояние),
— запросы (чтение),
— доменные события (что сервис публикует).
4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API.
4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки:
— ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency),
— какие — технические,
— как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку).
4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем
4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка
4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности
5. Надёжность, производительность, наблюдаемость
5.1. Для ключевых операций определены SLO:
— латентность
— доступность
— процент ошибок
5.2. Поведение при отказах: понятно, что делает сервис:
— при падении зависимого сервиса,
— при перегрузке (ограничение, деградация, очереди),
— есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок
5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам
5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке
5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования
1❤22👍11🔥6👏1🤣1
Если вам удобнее использовать Canvas — для микросервисов есть и он, конечно. Точнее, даже не для самих микросервисов, а для ограниченных контекстов (спасибо Денису Мигулину за наводку).
Разделы:
Название
Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы.
Стратегическая классификация, из трех частей:
💎 Уникальность — насколько этот контекст важен для успеха организации?
Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического?
⚙️ Роль в бизнес-модели:
— генерация прибыли,
— повышение вовлеченности/виральности,
— предотвращение рисков (регуляторных, репутационных, ...)
— снижение расходов
📊 Стадия эволюции (по Wardley map):
— Зарождение
— Заказная разработка
— Готовый продукт
— Типовое решение (commodity)
Архетип домена (роль):
— Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта)
— Исполнитель (выполняет или поддерживает исполнение бизнес-процесса)
— Аудитор (отслеживает выполнение)
— Контролер (принимает решение о возможности выполнения следующего шага, утверждает)
— Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами)
— Переводчик (переводит между разными "бизнес-языками")
— Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика)
— Пузырь (экранирует легаси-систему до её вывода)
— Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой)
— Аналитика (собирает и обобщает данные)
Язык домена: какие в этом контексте есть понятия и термины?
Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события.
У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста:
— OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст.
— CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream.
— ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне.
— SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание.
— PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться)
— Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития.
— PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR.
По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне.
Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы.
Бизнес-решения: какие приняты решения, политики и бизнес-правила.
Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались.
Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех?
Открытые вопросы: что ещё нужно выяснить?
Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.
Разделы:
Название
Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы.
Стратегическая классификация, из трех частей:
Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического?
— генерация прибыли,
— повышение вовлеченности/виральности,
— предотвращение рисков (регуляторных, репутационных, ...)
— снижение расходов
— Зарождение
— Заказная разработка
— Готовый продукт
— Типовое решение (commodity)
Архетип домена (роль):
— Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта)
— Исполнитель (выполняет или поддерживает исполнение бизнес-процесса)
— Аудитор (отслеживает выполнение)
— Контролер (принимает решение о возможности выполнения следующего шага, утверждает)
— Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами)
— Переводчик (переводит между разными "бизнес-языками")
— Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика)
— Пузырь (экранирует легаси-систему до её вывода)
— Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой)
— Аналитика (собирает и обобщает данные)
Язык домена: какие в этом контексте есть понятия и термины?
Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события.
У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста:
— OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст.
— CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream.
— ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне.
— SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание.
— PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться)
— Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития.
— PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR.
По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне.
Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы.
Бизнес-решения: какие приняты решения, политики и бизнес-правила.
Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались.
Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех?
Открытые вопросы: что ещё нужно выяснить?
Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2
Про аналитиков мы уже говорили, а откуда взялись архитекторы ПО?
Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов.
Об архитектуре программ тогда речь не шла; идея, что разные части программы неплохо как-то логично организовать: структурное программирование только-только появилась.
В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов.
Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах).
В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула:
Программная архитектура = {Элементы, Формы, Обоснования},
где Элементы делятся на элементы обработки, элементы данных и элементы связи,
а Формы — на взвешенные свойства элементов/системы и отношения между элементами.
В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает.
В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего.
Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем.
Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.
Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов.
Об архитектуре программ тогда речь не шла; идея, что разные части программы неплохо как-то логично организовать: структурное программирование только-только появилась.
В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов.
Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах).
В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула:
Программная архитектура = {Элементы, Формы, Обоснования},
где Элементы делятся на элементы обработки, элементы данных и элементы связи,
а Формы — на взвешенные свойства элементов/системы и отношения между элементами.
В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает.
В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего.
Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем.
Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.
👍13❤4🔥1