Переработка знаний становится нетривиальным процессом именно тогда, когда сами знания представляют собой нечто большее, чем набор объектов и числовых показателей — ведь в заданных правилах делового регламента (алгоритмах операций, соотношениях между понятиями предметной области) могут иметься противоречия. Специалисты обычно не осознают, насколько сложны происходящие у них в уме процессы: в ходе работы применяются соотношения и правила, устраняются противоречия, пробелы в знаниях заполняются с помощью интуиции и здравого смысла. Но программа ничего этого не умеет. Соотношения и правила предметной области должны проясняться, конкретизироваться, очищаться от противоречий или вообще отменяться в процессе совместной переработки знаний с участием программистов и специалистов.
Рубрика: ddd
Эрик Эванс о связи модели и языка обсуждения проекта
Используйте модель как основу для языка. Побуждайте разработчиков пользоваться им во всех видах внутригруппового взаимодействия, а также в коде. Пользуйтесь одним и тем же языком в диаграммах, письменной документации и особенно при
разговоре.
Устраняйте трудности путем экспериментирования с альтернативными выражениями, отражающими альтернативные модели. Затем выполняйте рефакторинг кода,
переименовывайте классы, методы и модули, чтобы добиться соответствия новой модели. Ликвидируйте путаницу в терминологии путем устных обсуждений — таким же
образом, как мы приходим к согласию о значении обычных слов.
Осознайте, что изменения в ЕДИНОМ ЯЗЫКЕ — суть изменения в модели.
Специалисты в предметной области должны возражать против терминов или структур, неудобно или недостаточно передающих суть явлений из их области. А разработчикам следует отслеживать любую неодзнозначность и непоследовательность, потому
что из-за них пострадает архитектура программы.
Эрик Эванс, определение термина «модель»
Модель — это набор понятий, существующих в головах у создателей проекта, вместе с названиями (терминами), отношениями и взаимосвязями, отражающими их понимание предмета. Термины и взаимосвязи образуют семантику языка, даптированного к предметной области, но достаточно точного и для технических нужд разработки. Это та нить, которая соединяет модель с кодом и позволяет ей органично вплетаться в процесс разработки.
Эрик Эванс о последствиях унификации модели в больших системах
Полная унификация модели предметной области для большой системы либо невозможна, либо
неоправданно затратна. Иногда люди пытаются бороться с этой реальностью. Большинство видит ту цену, которую приходится платить из-за ограниченной интегрированности и неудобств коммуникации между несколькими моделями. Кроме того, наличие нескольких моделей
субъективно кажется некрасивым. Это сопротивление использованию нескольких моделей иногда вызывает к жизни амбициозные попытки унифицировать все программное
обеспечение в рамках одного проекта под эгидой единой модели. Я знаю этот грех и за
собой.
Но рассмотрим же, чем это чревато.
- Слишком много уже имеющегося кода придется одновременно заменять на новый.
- Большие проекты могут затормозиться из-за того, что дополнительная нагрузка по управлению ими превзойдет имеющиеся возможности.
- Приложениям со специализированными требованиями могут быть навязаны такие модели, которые не полностью cooтветствуют их задачам, поэтому реализацию важных операций придется выносить куда-то в другое место.
- И напротив, попытка удовлетворить всех одной моделью добавит в нее столько вариантов и параметров, что ею станет трудно пользоваться.
Эрик Эванс о проблеме работы с несколькими моделями
В любом крупном проекте возникает необходимость работать с несколькими моделями. Но при комбинировании в одно целое кода, разработанного на основе сильно отличающихся моделей, программа становится ненадежной, трудной в понимании, склонной к сбоям. Запутывается коммуникация между членами группы. Часто бывает непонятно, в каком контексте модель не должна применяться.
Эрик Эванс о бреши в базе знаний
Между тем в любом проекте существующая база знаний может «дать течь». Например, уволились сотрудники, которые уже чему-то научились. Или рабочая группа реорганизовалась, и накопленные ею знания снова стали фрагментарными. Или, скажем, критически важные подсистемы отданы для разработки субподрядчикам, и те присылают код, но не передают соответствующие знания, лежащие в его основе. Как правило, проектирование программ выполняется так, что ни код, ни документация не выражают знания, обретенные тяжкими трудами, в явной, понятной форме. Если по какой-то причине прекращается устная передача знаний в группе, это означает их потерю.
Эрик Эванс «Предметно-ориентированное проектирование»
Эрик Эванс об отличии ddd подхода от устаревшего «каскадного»
Переработка знаний не осуществляется в одиночку. Для этой цели разработчики программы сотрудничают со специалистами в предметной области — как правило, руководя этим процессом. Вместе они привлекают информацию и перерабатывают ее в удобную форму. Исходное информационное сырье приходит от специалистов в предметной области, пользователей существующих систем, из опыта технических сотрудников проекта по работе с аналогичными, более ранними системами или другими проектами в той же области знания. Информация поступает в виде проектной или деловой документации, а также бесконечных устных дискуссий. Ранние версии программ или их прототипы дают группе обратную связь и помогают видоизменять ее взгляды на проблему.
В старой «каскадной методике» (waterfall тethod) специалисты по предметной области выдавали информацию аналитикам; те ее поглощали и абстрагировали, а затем передавали результат программистам, которые и писали программы. Этот подход неудачен, поскольку совершенно лишен обратной связи. Создание модели целиком возложено на аналитиков, а исходными данными им служит только информация от специалистов. Аналитики не имеют возможности научиться чему-либо у программистов или проанализировать результаты работы черновых версий программы. Знания протекают в одном направлении, но не накапливаются.
Эрик Эванс о составляющих успеха эффективного моделирования
1 . Установили связь между моделью и ее реализацией.
Уже в самом грубом прототипе присутствовала существенная связь с действительностью, и после всех последующих доработок эта связь сохранилась.
2. Ввели в обиход язык, основанный на модели.
Вначале инженерам приходилось объяснять мне элементарные понятия схемотехники, а мне — объяснять им, что такое схема взаимоотношений классов. Но по ходу проекта мы смогли вооружиться понятиями, взятыми из самой модели, составить из них предложения, согласующиеся со структурой модели, и в результате достичь полного понимания без переводчика.
3. Разработали информоемкую модель.
У объектов есть заданные правила поведения и ограничения. Наша модель была не просто схемой хранения данных, а целостной методикой решения сложных задач. Она содержала в себе и обобщала обилие информации разного рода.
4. Занимались дucстилляцией модели.
По мере того как создание модели близилось к завершению, в нее добавлялись важные понятия. Но также важно и то, что понятия, оказавшиеся бесполезными или второстепенными, были отброшены. Если бесполезное понятие было тесно связано с необходимым, то находилась новая модель, в которой существенное понятие легко отделялось, а второстепенное отбрасывалось.
5. Экспериментировали и nроводили мозговые штурмы.
Наличие общего языка, набросков схем и готовности к интеллектуальным прорывам превратили наши дискуссии в экспериментальную лабораторию по разработке модели, где «обкатывались» и оценивались сотни опытных вариантов. В процессе пошагового исследования рабочих сценариев даже устные высказывания участников срабатывали как быстрые тесты на пригодность предлагаемой модели, поскольку ухо человека легко отличает ясность и простоту от косноязычия.
В общем, именно творческий процесс мозгового штурма и интенсивного экспериментирования, облеченный в форму единого языка модели и направляемый обратной связью от программной реализации, сделал возможным создание информоемкой модели и ее дистилляцию. Знания, имеющиеся у коллектива разработчиков, превращаются в ценные для работы модели именно в результате такого процесса переработки знаний (knowledge crunching).
Эрик Эванс «Предметно-ориентированное проектирование»
Эрик Эванс о трех фундаментальных способах использования модели при разработке
Выбор модели в предметно-ориентированном проектировании определяется тремя фундаментальными способами ее использования при разработке программы.
1. Модель и арxuтектура программы взаимно определяют друг друга. Именно тесная связь между моделью и ее программной реализацией определяет важность и нужность самой модели, а также гарантирует, что проделанный при ее разработке анализ отражен в конечном результате, Т.е. в работающей программе. Связь между моделью и реализацией помогает также в процесс е дальнейшей доработки программы и выпуска ее новых версий, поскольку и сам программный код можно интерпретировать, основываясь на понимании модели.
2. Модель лежит в основе языка, на котором говорят все члены группы разработчиков. Ввиду связи между моделью и реализацией разработчики могут обсуждать все связанные с программой вопросы на этом языке, а также общаться со специалистами в предметной области без переводчика. Поскольку язык основывается на самой модели, возможности и средства естественного языка можно даже применить для доработки самой модели.
3 . Модель это дистиллированное знание. Модель представляет собой согласованный между разработчиками способ структуризации знаний из предметной области, а также выделения элементов, представляющих наибольший интерес. Модель передает наш способ мыслить о предмете, выраженный в выборе терминов, выделении понятий И установке связей между ними. Разработчики и специалисты в предметной области имеют возможность совместно переработать информацию в такую форму, поскольку для этого у них имеется общий язык. А связь между моделью и реализацией позволяет использовать опыт разработки ранних версий программы для корректировки самого процесса моделирования.
Эрик Эванс «Предметно-ориентированное проектирование»
Эрик Эванс о модели предметной области
Модель предметной области — это не некая нарисованная схема, а идея, которую схема должна отражать. Это не просто знания специалиста по данному предмету; это строго организованная выборка из такого знания. Схема может наглядно изображать модель, передавать информацию о ней, но того же самого можно добиться и при помощи программного кода или предложения на «человеческом языке». Моделирование предметной области не нацелено на создание максимально «реалистичной» модели. Даже в мире осязаемых, реальных вещей наша модель будет всего лишь искусственным творением. Но моделирование не состоит и в том, чтобы просто сконструировать программный механизм, который бы давал нужный результат. Процесс моделирования чем-то близок к съемке фильма — это тоже примерное изображение реальности , служащее конкретной цели. Даже в документальном фильме не показывают реальную жизнь совсем без прикрас. Как кинематографист выбирает отдельные аспекты реальной жизни и показывает их в своеобразном виде для раскрытия сюжета или передачи послания фильма, так и специалист, моделирующий предметную область, выбирает модель сообразно с ее применимостью .
Эрик Эванс «Предметно-ориентированное проектирование»