«Еще одно важное изменение, которое принес DDD, — признание, что единую непротиворечивую модель предметной области построить невозможно, а значит и не стоит браться за эту задачу.»
Насколько помню, те же самые идеологи и методисты ErWin говорили, что для построения модели надо выбирать точку зрения и большую модель бить на части.
смотри:
« Для более удобной работы с большими моделями в ERwin предусмотрены подмножества модели(Subject Area), в которые можно включить тематически общие сущности.»
что говорит именно DDD, и что я понял не сразу — что он предлагает один и тот же объект реального мира моделировать по-разному, а не просто разбивать на контексты. в этом есть большой смысл, которого не было ранее
«Ведь если заказчик и пользователи понимают модель системы, то они сами могут оценить, подойдет она для их целей или нет. »
А почему это не сработало с макетами интерфейсов? Вроде макеты интерфейсов — это тоже модель системы. Вот тебе вход, вот выход. Чего не хватило? Диаграммы алгоритмов? Ок, вот макет интерфейса + диаграмма алгоритма. Зачем DDD?
«Они заменили две модели, предметной области и системы, на единую модель, описанную на едином языке проекта.»
Какая модель имеется в виду? Модель чего, системы?
«На рисунке мы видим описание бизнес-процессов в виде activity diagram, диаграмму классов для документов и диаграмму состояний документов, которые и реализуют бизнес-процесс. Но при этом все три модели — на едином языке и с прозрачной связью между ними. И принципы DDD говорят, что в коде информационной системы должны присутствовать те же самые объекты, а не какая-то другая реализация.»
Если ты тут показываешь модель системы, то я её тут не вижу, есть модель автоматизируемой деятельности и её правил.
«Таким образом, DDD сместил фокус от описания системы как черного ящика к описанию внутреннего устройства, или системы прозрачного ящика.»
От многих аналитиков-проектировщиков и раньше и сейчас требуют, чтобы они описывали структуру системы и её частей, ранее через UML-диаграммы Крухтеновского 4+1 и подсистемы-модули по ГОСТ + алгоритмы обработки данных и даже сигнатуры вызовов и DDL-скрипты и диаграммы классов Boundary-Control-Entity, а сейчас — через C4-модель.
В общем сейчас ты похож на фанатиков-агилистов, которые утверждают, что до agile в софтверной индустрии была голь перекатная и один waterfall :)
«Это был следующий шаг по отношению к рекомендованному на этапе анализа составлению словаря предметной области: мы говорим, что у нас теперь будет не просто словарь понятий, а набор объектов со своими атрибутами и методами.»
И опять-таки всё это было и мы практиковали в середине 2000-х благодаря UML, RUP и Iconix. Мы делали объектную модель анализа.
Насколько я понимаю, прозрачно отражать объекты предметной области в код предложил не DDD, а сами создатели объектно-ориентированных языков типа SmallTalk и те же соавторы OOAD в форме UML и RUP.
Это уже потом пришли ремесленники и нагородили паттернов типа инъекций, фасада, фабрики и т.д., за которыми стало не видно ключевых объектов приложения, моделирующих реальность.
«Таким образом, получалось две модели: модель предметной области, обычно в виде бизнес-процессов, с которой работал бизнес-аналитик»
Модель предметной области всегда была прежде всего онтологической моделью, сначала — ER-диаграммой (смотри методологию IDEF1FX 70-х годов и моду на ERWin в 90-х), потом — UML Class (см RUP и OOA).
Модель предметной области обычно фиксирует общее устройство реальности в отрасли (статическая модель отношений явлений и бизнес-объектов), а не в конкретной компании — в этом её сила для повторного использования (см Analysis Patterns Фаулера) и в этом же её слабость (см неуспех той же книжки).
Мне как инженеру и разработчику БД было нормальное рисовать концептуальные модели предметки как онтологии, но заказчикам их пользу приходилось объяснять с большим трудом.
Когда в роли бизнес-аналитиков стали выступать вчерашние лингвисты и экономисты, им конечно было проще описывать модель процессов, а не домена.
Ну и, что самое важно, заказчикам процессные модели были понятнее, чем онтологические и формально правильные.
И в целом побеждали и победили смешанные неформальные модели деятельности с объектами swimlane flowchart, откуда вылез и закрепился успех BPMN (а теперь глядишь и Event Storming).
вот смотри, получается, что у БА возникает очень большой соблазн сразу от требований вида:
- организация должна формировать и отправлять клиентам коммерческое предложение
перейти к требованиям к системе вида
- ИТ-система должна позволять сформировать коммерческое предложение для клиента - ИТ-система должна позволять отправить коммерческое предложение клиенту
и может дополнить их количественными ограничениями
и да, в этот момент уже функции «закрыты» таким описанием, Word и Outlook отброшены по непонятной причине
я делаю вывод, что пропущено создание концепции ИТ-решения, т.е. генерация, презентация, обсуждение и выбор конкретного набора технологий для автоматизации того или иного участка деятельности
предлагаемый тобой и индустрией DDD частично заменяет концепцию ИТ-решения, но опять-таки неявно наводит команду на один конкретный вариант автоматизации по принципу «мы умеем 1С, поэтому всё будет в 1 С»
Ты мне кажется очень резво перескакиваешь в 1999-й год.
Работа с требованиями всегда существовала в традиционной инженерии и системной инженерии, только ей кажется не уделялось особого внимания.
Там насколько я понимаю, была следующая цепочка запросов:
любой более-менее сложный объект невозможно сделать одной организации, нужно сотрудничество нескольких
чтобы сотрудничество получилось, надо выдать партнёрской организации задание на создание части объекта (ТЗ)
чтобы выдать задание на создание части объекта, нужно сначала спроектировать объект целиком
чтобы спроектировать правильный объект целиком, надо поставить задачу на его проектирование
и вот тут были разные школы:
а) школа духа auftragstaktik — когда постановка на проектирование идёт на уровне цели, критериев успеха и, возможно, ограничений
б) школа «детальных и иерархических требований» — пока не до конца понятно, как она появилась, но она базируется на вроде бы логичной концепции, что если мы опишем модель применения объекта целиком, то сможем выйти на его свойства. по факту это получается уже не постановка задачи на проектирование, а его первый этап — функциональное проектирование. при этом было неочевидно, что функциональное проектирование опасно делать в отрыве от конструктивных возможностей.
При этом в системной инженерии задача производства и сборки большого объекта из поставок разных организаций никуда не девалась и появилась целая иерархия уровней требований — а по сути, форматов частей заданий на поставку, например, в ISO 29148:
Business Requirements
Stakeholder Requirements
System Requirements
Software Requirements
Такой иерархический, синий по СД подход очень импонирует людям, взращенным в культуре порядка и подчинения. То, что он не очень уж однозначно и хорошо работает, было понятно конструкторам внутри машиностроения, строительства и т.д., но наружу это особо не выносилось.
-
Как человек, которому приходилось много раз переделывать свой код, могу сказать, что в такой ситуации возникает естественная гипотеза и запрос — «дайте нормальное ТЗ»! А нормальное ТЗ дать не могут, потому что код типа легко править и нет желания заниматься фазой проектирования. Кто должен проектировать в типовой связке «заказчик» + «младший разработчик»? Никто не проектирует, поэтому остаётся только договариваться о процедуре приёмки, которая в идеале основана на модели использования.
А модель использования — это серая зона проектирования между заказчиком и разработчиком. Вот и возникает обманчивое желание сделать правильные БИЗНЕС-требования, которые-де станут путеводной звездой для конструктора-непроектировщика.
А дальше есть отдельная эпопея, как понятие бизнес-требований (по сути это требования к capability организации) оказалось извращено до «идеи о функциях и свойствах софта, которые выдвигают представители бизнеса».
У меня заняло много лет дойти до понимания, что нормальное БТ — это «организация X должна формировать и отправлять клиентам коммерческое предложение», без упоминания каких-либо систем в явном виде. Может по-этому требования стали больным местом, красной тряпкой и местом споров.
> "With close supervision, acts as a liaison between one or more business system users such as finance, payroll, purchasing, marketing, manufacturing, and/or human resources and the information systems technical staff to ensure information technology design, data, reports, systems and processes meet the needs of the department(s)."
... выступать посредником между пользователями таких БИЗНЕС-СИСТЕМ, как — финансы, зарплата, закупки, маркетинг, производство, кадры...
Хочу отметить, что почти во всех вакансиях указано название позиции "бизнес- системный аналитик". То есть здесь не завуалировано, а напрямую и сразу сообщают, что придется делать все и сразу, и вчера.
Это не 2 роли в одной, Business Systems Analyst переводится с английского как «аналитик бизнес-систем», т.е. аналитик систем, автоматизирующих конкретный бизнес (в отличие от продуктов, игр и т.д.)
По поводу видео из Контура — аналитик из продуктовой компании изучала опыт продуктовых компаний. Как видим, результат — в продуктовой разработке СА не очень-то востребованы.
Но зато во внутренней разработке и заказной — совсем другая ситуация.
«Еще одно важное изменение, которое принес DDD, — признание, что единую непротиворечивую модель предметной области построить невозможно, а значит и не стоит браться за эту задачу.»
Насколько помню, те же самые идеологи и методисты ErWin говорили, что для построения модели надо выбирать точку зрения и большую модель бить на части.
смотри:
« Для более удобной работы с большими моделями в ERwin предусмотрены подмножества модели (Subject Area), в которые можно включить тематически общие сущности.»
https://studfile.net/preview/5828092/page:16/
1999-й год, даже не 21-й век!
что говорит именно DDD, и что я понял не сразу — что он предлагает один и тот же объект реального мира моделировать по-разному, а не просто разбивать на контексты. в этом есть большой смысл, которого не было ранее
«Ведь если заказчик и пользователи понимают модель системы, то они сами могут оценить, подойдет она для их целей или нет. »
А почему это не сработало с макетами интерфейсов? Вроде макеты интерфейсов — это тоже модель системы. Вот тебе вход, вот выход. Чего не хватило? Диаграммы алгоритмов? Ок, вот макет интерфейса + диаграмма алгоритма. Зачем DDD?
«Этим DDD в значительной мере обесценил требования как таковые и внимание к ним.»
Опять-таки, ещё раньше требования были сначала обесценены use case'ами, а после — user stories.
При этом проблема формулирования качественных ограничений, в том числе показателей качества, остаётся и DDD вроде никак её не решает.
«Они заменили две модели, предметной области и системы, на единую модель, описанную на едином языке проекта.»
Какая модель имеется в виду? Модель чего, системы?
«На рисунке мы видим описание бизнес-процессов в виде activity diagram, диаграмму классов для документов и диаграмму состояний документов, которые и реализуют бизнес-процесс. Но при этом все три модели — на едином языке и с прозрачной связью между ними. И принципы DDD говорят, что в коде информационной системы должны присутствовать те же самые объекты, а не какая-то другая реализация.»
Если ты тут показываешь модель системы, то я её тут не вижу, есть модель автоматизируемой деятельности и её правил.
я напомню, что в RUP были 3 сквозных процесса-дисциплины на эту тему:
Business Modeling
Requirements
Analysis and Design
не сводилось всё к требованиям и чёрному ящику
«Таким образом, DDD сместил фокус от описания системы как черного ящика к описанию внутреннего устройства, или системы прозрачного ящика.»
От многих аналитиков-проектировщиков и раньше и сейчас требуют, чтобы они описывали структуру системы и её частей, ранее через UML-диаграммы Крухтеновского 4+1 и подсистемы-модули по ГОСТ + алгоритмы обработки данных и даже сигнатуры вызовов и DDL-скрипты и диаграммы классов Boundary-Control-Entity, а сейчас — через C4-модель.
В общем сейчас ты похож на фанатиков-агилистов, которые утверждают, что до agile в софтверной индустрии была голь перекатная и один waterfall :)
«Это был следующий шаг по отношению к рекомендованному на этапе анализа составлению словаря предметной области: мы говорим, что у нас теперь будет не просто словарь понятий, а набор объектов со своими атрибутами и методами.»
И опять-таки всё это было и мы практиковали в середине 2000-х благодаря UML, RUP и Iconix.
Мы делали объектную модель анализа.
http://dit.isuct.ru/Publish_RUP/extend.bus_model/capabilitypatterns/develop_domain_model_82AFF35C.html_desc.html
«DDD предложил так же, через объекты, описывать предметную область, а затем прозрачно отражать объекты предметной области в код.»
Описывать предметную область через объекты предложил не DDD, а ещё OOA — Object-Oriented Analysis (and Design) Гради Буча и компании: https://www.wikiwand.com/en/Object-oriented_analysis_and_design
Насколько я понимаю, прозрачно отражать объекты предметной области в код предложил не DDD, а сами создатели объектно-ориентированных языков типа SmallTalk и те же соавторы OOAD в форме UML и RUP.
Это уже потом пришли ремесленники и нагородили паттернов типа инъекций, фасада, фабрики и т.д., за которыми стало не видно ключевых объектов приложения, моделирующих реальность.
«Таким образом, получалось две модели: модель предметной области, обычно в виде бизнес-процессов, с которой работал бизнес-аналитик»
Модель предметной области всегда была прежде всего онтологической моделью, сначала — ER-диаграммой (смотри методологию IDEF1FX 70-х годов и моду на ERWin в 90-х), потом — UML Class (см RUP и OOA).
Модель предметной области обычно фиксирует общее устройство реальности в отрасли (статическая модель отношений явлений и бизнес-объектов), а не в конкретной компании — в этом её сила для повторного использования (см Analysis Patterns Фаулера) и в этом же её слабость (см неуспех той же книжки).
Модель процессов обычно описывает устройство процессов в конкретной компании, а не в отрасли, т.к. считается, что они сильно изменчивы от компании к компании, хотя и есть инициативы типы APQC Reference Model, но они видимо известны только бизнес-архитекторам (https://www.apqc.org/resource-library/resource-listing/apqc-process-classification-framework-pcf-cross-industry-excel-10)
Мне как инженеру и разработчику БД было нормальное рисовать концептуальные модели предметки как онтологии, но заказчикам их пользу приходилось объяснять с большим трудом.
Когда в роли бизнес-аналитиков стали выступать вчерашние лингвисты и экономисты, им конечно было проще описывать модель процессов, а не домена.
Ну и, что самое важно, заказчикам процессные модели были понятнее, чем онтологические и формально правильные.
И в целом побеждали и победили смешанные неформальные модели деятельности с объектами swimlane flowchart, откуда вылез и закрепился успех BPMN (а теперь глядишь и Event Storming).
вот смотри, получается, что у БА возникает очень большой соблазн сразу от требований вида:
- организация должна формировать и отправлять клиентам коммерческое предложение
перейти к требованиям к системе вида
- ИТ-система должна позволять сформировать коммерческое предложение для клиента
- ИТ-система должна позволять отправить коммерческое предложение клиенту
и может дополнить их количественными ограничениями
и да, в этот момент уже функции «закрыты» таким описанием, Word и Outlook отброшены по непонятной причине
я делаю вывод, что пропущено создание концепции ИТ-решения, т.е. генерация, презентация, обсуждение и выбор конкретного набора технологий для автоматизации того или иного участка деятельности
предлагаемый тобой и индустрией DDD частично заменяет концепцию ИТ-решения, но опять-таки неявно наводит команду на один конкретный вариант автоматизации по принципу «мы умеем 1С, поэтому всё будет в 1 С»
Ты мне кажется очень резво перескакиваешь в 1999-й год.
Работа с требованиями всегда существовала в традиционной инженерии и системной инженерии, только ей кажется не уделялось особого внимания.
Там насколько я понимаю, была следующая цепочка запросов:
любой более-менее сложный объект невозможно сделать одной организации, нужно сотрудничество нескольких
чтобы сотрудничество получилось, надо выдать партнёрской организации задание на создание части объекта (ТЗ)
чтобы выдать задание на создание части объекта, нужно сначала спроектировать объект целиком
чтобы спроектировать правильный объект целиком, надо поставить задачу на его проектирование
и вот тут были разные школы:
а) школа духа auftragstaktik — когда постановка на проектирование идёт на уровне цели, критериев успеха и, возможно, ограничений
б) школа «детальных и иерархических требований» — пока не до конца понятно, как она появилась, но она базируется на вроде бы логичной концепции, что если мы опишем модель применения объекта целиком, то сможем выйти на его свойства. по факту это получается уже не постановка задачи на проектирование, а его первый этап — функциональное проектирование. при этом было неочевидно, что функциональное проектирование опасно делать в отрыве от конструктивных возможностей.
При этом в системной инженерии задача производства и сборки большого объекта из поставок разных организаций никуда не девалась и появилась целая иерархия уровней требований — а по сути, форматов частей заданий на поставку, например, в ISO 29148:
Business Requirements
Stakeholder Requirements
System Requirements
Software Requirements
Такой иерархический, синий по СД подход очень импонирует людям, взращенным в культуре порядка и подчинения. То, что он не очень уж однозначно и хорошо работает, было понятно конструкторам внутри машиностроения, строительства и т.д., но наружу это особо не выносилось.
-
Как человек, которому приходилось много раз переделывать свой код, могу сказать, что в такой ситуации возникает естественная гипотеза и запрос — «дайте нормальное ТЗ»! А нормальное ТЗ дать не могут, потому что код типа легко править и нет желания заниматься фазой проектирования. Кто должен проектировать в типовой связке «заказчик» + «младший разработчик»? Никто не проектирует, поэтому остаётся только договариваться о процедуре приёмки, которая в идеале основана на модели использования.
А модель использования — это серая зона проектирования между заказчиком и разработчиком. Вот и возникает обманчивое желание сделать правильные БИЗНЕС-требования, которые-де станут путеводной звездой для конструктора-непроектировщика.
А дальше есть отдельная эпопея, как понятие бизнес-требований (по сути это требования к capability организации) оказалось извращено до «идеи о функциях и свойствах софта, которые выдвигают представители бизнеса».
У меня заняло много лет дойти до понимания, что нормальное БТ — это «организация X должна формировать и отправлять клиентам коммерческое предложение», без упоминания каких-либо систем в явном виде. Может по-этому требования стали больным местом, красной тряпкой и местом споров.
как человек, который 8 лет не мог ответить на комментарий, ты не в той позиции, чтобы читать мне нотации
чтобы перестать брызгать слюной, шипеть "некомпетентносссссть" и проч, рекомендую пройти курс психотерапии
в 21-м веке уже немодно быть воинственным социопатом и психопатом
Это всё связанные вещи, странно этого не понимать.
смотря какая цель публикации.
если продемонстрировать экспертизу OTUS — это одно.
но тут видимо что-то другое
см. текст вакансии со скриншота:
> "With close supervision, acts as a liaison between one or more business system users such as finance, payroll, purchasing, marketing, manufacturing, and/or human resources and the information systems technical staff to ensure information technology design, data, reports, systems and processes meet the needs of the department(s)."
... выступать посредником между пользователями таких БИЗНЕС-СИСТЕМ, как — финансы, зарплата, закупки, маркетинг, производство, кадры...
Это не 2 роли в одной, Business Systems Analyst переводится с английского как «аналитик бизнес-систем», т.е. аналитик систем, автоматизирующих конкретный бизнес (в отличие от продуктов, игр и т.д.)
По поводу видео из Контура — аналитик из продуктовой компании изучала опыт продуктовых компаний. Как видим, результат — в продуктовой разработке СА не очень-то востребованы.
Но зато во внутренней разработке и заказной — совсем другая ситуация.
Отдельно интересно, что по данным indeed, Systems Analyst (именно в такой форме, без бизнеса) входит в TOP-100 самых высокооплачиваемых профессий — позиция 82: https://www.indeed.com/career-advice/finding-a-job/top-100-highest-paying-jobs
это видимо автор младшекурсный реферат запилил сюда
ладно бы из гостов — так ведь и ответа на вопрос "как" в статье нет :(
только какие-то занудствования и стенания о "негативных ситуациях"
а что ты, автор, сделал, чтобы было лучше? судя по статье — ничего
а где в этом процессе связь с архитектурой?
где работа с атрибутами качества и ограничениями?