Часто спрашивают о соотношении нескольких популярных методологий разработки, которые находятся на слуху: use case, DDD, BDD (TDD). При этом все эти методологии бурно развиваются:
– только что вышла версия Use Case 3.0 (https://www.ivarjacobson.com/files/use-case_3_ebook.pdf). Там впрямую расширение использования сценариев до методологии разработки (то есть как нарезать работу создателей системы на куски).
– лидирующая методология разработки DDD (Domain-driven design - Wikipedia), где не говорится про сценарии, но зато говорится про события (и там даже где-то рядом одна из методологий начального подхода к работе с domain/“предметной областью” по методу DDD – Event Storming, Event storming - Wikipedia).
– BDD (Behavior-driven development - Wikipedia) получила язык Gerkin, при этом корни там из TDD, а заголовки впрямую пересекаются со “сценариями” (cases) из use cases, например, “Writing scenarios with Gherkin syntax”, Writing scenarios with Gherkin syntax | CucumberStudio Documentation
– большинство этих методологий до сих пор (они же уже довольно давно родились) поминают слово “требования”, которых вроде уже нет, а также никак не относятся к новым веяниям в архитектуре (хотя в современных версиях DDD такие попытки и делаются).
Как это всё соотносить друг с другом? На эту тему у нас есть несколько курсов:
– “Рациональная работа” научит более-менее строго читать тексты всех этих методологий, чтобы “смотреть в книгу, не видеть фигу”. Прежде всего, обращать внимание не на слова, а на типы. И удерживать эти типы во внимании в ходе рассуждений (собранность). Главное – это не путать описания, поведения, свойства, состояния, объекты (без этого все рассуждения не могут быть проведены, будет каша – обсуждение бега без бегуна, сценариев с неразличением его прохождения от его описания, вопросами вроде “а что вместо требований” и т.д.).
– “Системное мышление” заставит все рассуждения выстраивать по поводу разных систем в графе создания и находить эти системы.
– “Методология”, в которой рассматривается подробно поведение систем, в том числе методы создания и развития одних систем (создаваемых) другими (создателями).
То, что требуется в ответе на вопрос про популярные методологии разработки – это понять, как их все соотносить друг с другом. В науке такое называется “синтезом” (например, эволюционный синтез – это когда теорию Дарвина о естественном отборе скрестили с теорией Менделя о генах, modern synthesis – когда скрестить пришлось уже много подобных “частных теорий”, https://en.wikipedia.org/wiki/Modern_synthesis_(20th_century), а extended synthesys – когда пришлось включать и культурную эволюцию, и ещё много чего другого, Extended evolutionary synthesis - Wikipedia). Вопрос про DDD, Use Cases, BDD и всё подобное – “дайте современный синтез всех этих методологий”.
Ответ лежит в ситуационной инженерии методов: методологии, которая была бы универсальна для всех проектов, не бывает. Вам придётся сделать такой синтез самостоятельно, силами методолога разработки (необязательно софтверной!), который занимается вашим инженерным (необязательно software!) процессом.
Главным тут будет DDD – как раз там ничего не говорится про “сценарии”, но вводится простая мысль: софт представляет собой модель предметной области, при этом модели программы как можно ближе должны отражать объекты предметной области. Хинт: по факту нет никакой “предметной области”, есть винегрет из самых разных предметных областей, поэтому главное понятие тут – bounded context. Понятие “события” неявно вводит изменения состояний каких-то предметов метода, и требуется явное моделирование этих предметов метода и их состояний в ходе некоторых операций. Курс “Рациональная работа” занят в части рациональности ровно вот этим – моделированием. Ещё нет систем, нет понимания методов – но DDD говорит, что надо как-то отмоделировать объекты “бизнесОв” (а не внутренние представления в голове программистов – то есть в модели должны быть “счета, запасы”, а не “массивы, структуры”) в виде то ли схемы базы данных, то ли структур данных объект-ориентированного (поначалу) или даже функционального (уже такое бывает иногда) языка программирования, а операции моделировать в виде операций на этом языке программирования (с базой данных тут сразу сложней), и делать это надо с учётом множества предметных областей. Это по факту методика онтологической работы, часть моделирования курса рациональной работы.
BDD – это развитие TDD, behavior тут отсылка к методу. Так что основное тут – методология. Процессы/сценарии/нарративы тут документируются в форме тестов, которые описываются на каком-то языке для инструментов тестирования. Описать процесс – это описать набор тестов, в которых процесс покажет ожидаемое поведение. Проверяются состояния каких-то объектов, в которые они приходят после операций. Те же “чеклисты” из курса “методология”, только не для менеджеров на языке табличек, а для софта на языке тестов (например, Gherkin как язык тестов для системы тестирования Cucumber). Требований нет, есть тесты. Испорченного телефона с “аналитиками” нет, сразу пишем тесты – по итогам моделирования процессов в DDD. Если DDD работает, то тестироваться будет правильная функциональность (“бизнесОв”), а не программистские галлюцинации по поводу того, что они там услышали (“я понял, там у них задействованы три массива и стек” – вот с этим и боремся, различаем domain прикладной и программистский).
Use Case – это не столько онтологический процесс (хотя тут тоже призывают определиться с объектами), сколько методологический. В его основе – метод/сценарий/case/flow. При этом отдельно подчёркивается, что описание метода/сценария/case/flow может быть любым (необязательно классическая нотация из начальных текстов по Use Case и необязательно из UML), описание сценария использования называют моделью сценария использования (use-case model). По факту сценарии выражаются в виде каких-то императивных “шагов”, приближающих к цели каких-то агентов (в широком понимании, необязательно живых) в окружении системы. И это не агенты-создатели обычно, именно агенты в окружении. И примеры там тоже – customer eXperience, где customer journey даётся как последовательность шагов. Дальше – нарезка на slices (ломтики – с удивительным составом из частных сценариев, каких-то проектов/design, кода, а также всяческих идей по нарубке на работы – и там user stories как совершенно не конкурирующий с use case и use case slice объект, а также tasks и features, в этом месте онтологи зажмуриваются, ибо это “результат” выделения слайса, тип work item), где затрагивается вопрос эволюции системы (лезем в понятия релиза, инкремента и прочей нарубки работы на рабочие единицы/items). А требования? Чётко говорится, прямо на концептуальной схеме: “требования документируются как use case” (requirements captured as use case), при этом помним, что форма выражения – неважна. Как это всё связано с DDD? Художественно. Никаких следов, это самодостаточная методология разработки на текущий момент. Предметных областей нет, есть сценарии, слайсы, предметы работы. А тесты? Ну, есть test case, он верифицирует use case slice. События? Учтены: поток событий называется нарративом, нарратив источник набора use case.
Как это всё сочетать? По вкусу! А чтобы разобраться и не запутаться, надо просто более-менее чётко делать контроль типов – типы можно брать из наших курсов. Скажем, тот же “нарратив” из Use Case – это очень похоже на граф состояний альфы из курса “Методология”. Дальше помним, что “состояния альф меняются какими-то методами”. Да, метод – это и есть сценарии/cases (то, что это “сценарии”, тоже описывается в курсе). То, что requirements captured as use case – читаем так, что “инженер ходит по разным проектным ролям и выявляет нарративы, то есть объекты с их состояниями, это как в DDD. По ним формулирует последовательности операций, приводящих к событиям в нарративах, затем записывает как use case models. Вот эти use case models и будут документами требований. Затем делает текст кейсы”. Связки с работами архитектора, bounded contexts – намёк на это есть в понятии слайсов, но не больше чем намёк, и там ещё и труднопереводимое addressing и уже знакомое aspect of the system – как раз "учёт разных ролевых рассмотрений, разных areas (of concern!) of the system, разных domain для предметов и операций разных методов, задействуемых разными ролями. “By addressing each aspect of the system slice by slice, use cases help with all the different areas of the system including user experience (user interface), architecture, testing, and planning. They provide a way to link the requirements to the parts of the system that implement them, the tests used to verify that the requirements have been implemented successfully, and the release and project plans that direct the development work. In Use-Case 3.0 there is a special construct, called the use-case realization, which is added to each use case to record its impact on the other aspects of the system”. После наших курсов всё это должно быть понятно, ибо должно в голове читателя маркироваться какими-то типами из наших курсов. Не ждите, что Якобсон хоть какой-то онтолог, он тут предпочитает действовать интуитивно в старой школе: “архитектор – это опытный разработчик”. Вперёд, с этого момента понятно, о чём там вообще эти Use Cases.
Примерно по той же линии можно рассуждать про DDD и BDD (с BDD полезно ещё почитать материал про инженерные обоснования из “Системного мышления”, ибо не всё там берётся через автоматизированное тестирование). И можно смешивать какие-то части всех этих методик во что-то, что подходит вашей организации, делать “методологический синтез”. Это, конечно, занятие методолога инженерной разработки. Одной интуицией и “здравым смыслом” в методологическом синтезе (синтезе нескольких методологий, как эволюционный синтез – синтез разных отдельных частных теорий, которые объясняют эволюцию) тут не обойдёшься – про все эти онтологии-методологии надо знать, иначе запутаешься в первые пять минут.
Там, конечно, много засад. Скажем, UX из цитаты, где в скобках UI. В недавнем обновлении “Методологии” я писал про идеи движения stakeholders eXperience – это учёт общей ситуации, в которой проектная роль получает впечатления (намёк на то, что если ты приготовил шикарный борщ, а в ресторане воняет бензином, то впечатления от борща будут плохие, хотя дело тут не в борще). И таких тонкостей в тексте – множество, включая areas of system, где это areas of concerns (области интереса) системы, термин из OMG Essence. В курсах наших всё это есть, поэтому сначала курсы – потом смотрим эти методологии, потом спокойно делаем из них коктейль/синтез, адаптированный к условиям вашего проекта.
Мой пойнт тут в том, что надо просто “иметь глаза”, чтобы вычитывать не бытовые слова изо всех этих текстах. И находить огромные дыры – иногда они в понимании авторов этих методик, а иногда – просто это авторами методики понимается как что-то из соседнего метода, которым занимаются не они сами. Ещё надо понимать:
– непрерывное всё тут не только про разработку системы, но и про разработку создателя. Так что подхакивать этот “синтез” придётся всё время. Эволюция неостановима, методолог инженерной разработки может только начать разрабатывать свою прикладную методологию для своего проекта, но не может её закончить.
– сами методы меняются и размножаются, Use Case тут самый древний, хоть и версии 3.0 (дай бог здоровья Ивару Якобсону, он и четвёртую версию выпустит через пару лет), DDD бодро эволюционирует, TDD уже эволюционировал в BDD, и это тоже продолжается. Следите за новинками.
– увы, в этом синтезе очень много чего не учтено. Так, описание поведения системы понятно как делать, и тут говорится о том, что разработчики должны сами ходить к исполнителям внешних проектных ролей, чтобы выпытать у них все эти нарративы/альфы, сценарии/методы, про то, что там важна роль прикладного методолога (и все эти методы и отдельные фичи крайне предметоспецифичны – методологи точно не “сверху вниз” разложение методов делают!) ни слова, ибо это ещё слишком фронтир. А вот эволюционная архитектура – уже не совсем фронтир, но там архитектор тоже интересуется, что будет с его системой, чтобы определить архитектурные характеристики. Вот про это – ни слова, “мы вам расскажем про разработчиков, точнее, методологов в их связке с visionary, которые и дают разбивку на ломтики с приоритетами, если use cases, или опишут набор предметных областей с их границами, но вот архитектурная работа – там отдельные книжки, мы просто упомянем, что это важно. Ах, и ещё безопасники, им тоже надо ходить к клиентам, что-то там выспрашивать, тоже отдельные книжки, синтезируйте в свой метод и что-то из них”.
