WWW.LIBRUS.DOBROTA.BIZ
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - собрание публикаций
 

Pages:     | 1 |   ...   | 2 | 3 || 5 |

«Мартина ФаУflера Предметно-ориентированное П оекти ОБ иие еТРУКТУРИ3АЦИЯ елО жныIx ПРО rPAMMHbIX СИ еТЕМ Domain -Driven Design TACKLING COMPLEXITY IN ТНЕ HEART OFSOFTWARE Eric Evans Addison-Wesley ...»

-- [ Страница 4 ] --

В этом втором цикле интеграции моделей возникла тенденция отбрасывания сл учай ­ ных или некорректных аспектов отдельных моделей, а также создания новых п онятий :

332 ЧАсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ "животного" с частями "хобот", "нога", "туловище" и хвост. Каждая из этих частей имеет собственные свойства и четкие взаимосвязи с другими частями. Успешная унификация моделей в значительной мере опирается на принцип минимализма. Хобот слона одно­ временно и нечто большее, и нечто меньшее, чем змея. Но "меньшее" здесь, вероятно, важнее, чем "большее". ЛУЧIllе обойтись без умения разбрызгивать воду, чем приобрести неправильное свойство "ядовитые зубы" .

Если цель состоит только в том, чтобы найти слона, то достаточно ввести трансляцию между выражениями местонахождения в каждой модели. Но если требуется более тесная интеграция, то не обязательно пытаться получить совершеННУIО модель уже в первой вер­ сии. Для каких-то целей будет достаточно представить слона как стену, стоящую на стволах деревьев, с веревкой на одном конце и змеей на другом. Позднее, под влиянием новых тре­ бований, лучшего пони мания и коммуникации, модель можно будет усовершенствовать .

Признавать существование нескольких противоречащих друг другу моделей предмет­ ной области - это означает просто принимать реальность такой, какой она есть. Определив контекст, внутри которого примснима каждая из моделей, можно сохранить целостность каждой из них и четко увидеть смысл любого из интерфейсов, которые можно построить между двумя моделями. У слепцов нет возможности увидеть всего слона, но их конкретные задачи вполне можно решить, если они признают неполноту своего восприятия .

Выбор стратегии построения контекстов Всегда важно в нужный момент иметь п еред собой КАРТУ KOI-ITEKCTOB (CONTEXT МАР), отражающую теКУЩУIО реальность. Но как только такая карта построена, можно браться за изменение самой этой реальности. Можно приступать к сознательному выбо­ ру границ KOI-[TEKCTA и его взаимосвязей. В этом разделе даются некоторые рекоменда­ ции, как это делать .

Уровень принятия решений: разработчики или выше llрежде всего разработчики должны принять реlпение, где именно определить ОГРАН ИЧЕННЫЕ КОНТЕКСТЫ и какие взаимосвязи между ними установить. Эти решения должны п риниматься всей группой разработчиков. Или, по крайней мере, они должны доводиться до сведения каждого члена группы и быть ему п онятными. Такие решения на самом деле часто бывают связаны с договорными отношениями за пределами одной группы. В идеале решение о том, следует расширять или разделять тот или иной КОНТЕКСТ, нужно принимать, взвесив издержки и преимущества как независимой рабо­ ты группы, так и прямой тесной интеграции, и найдя некий компромисс между ними. На практике же интеграцию систем часто опредеЛЯIОТ политические отношения между группами разработчиков. Технически полезная унификация оказывается невозможной из-за системы отчетности. Неудобное слияние может диктоваться системой руководства .

Не всегда удается получить то, что хочешь, но надо стараться оценить хотя бы kaKYIO-ТО часть издержек, донести эту информацию до других и предпринять меры по исправле­ нию положения. Начните с реальной карты контекстов и проектируйте изменения на ней с сугубо прагматической точки зрения .

Помещение самих себя в контекст Когда мы работаем над программным проектом, нас интересуют больше всего те час­ ти системы, которые затрагивает наша группа ( "проектируемая система"), а затем те системы, с которыми она поддерживает связь. Как правило, проектируемая система окаГЛАВА 14. ПОДДЕРЖАНИЕ ЦЕЛОСТНОСТИ МОДЕЛИ 333 зывается встроенной в один или два ОГРАНИЧЕННЫХ КОНТЕКСТА, над которыми работа­ ют главные разработчики, и может быть, еще в один или два вспомогательных. Кроме то­ го, есть связи и отношения между э тими КОНТЕКСТАМИ и внешними системами. Это обычная картина, примерно представляющая то, что встречается чаще всего .





Но на самом деле и мы сами входим в тот КОНТЕКСТ, над которым работаем. Это обя­ зательно нужно отразить в нашей КАРТЕ КОНТЕКСТОВ. В этом нет никакой проблемы, ес­ ли мы осознаем свою субъективность и знаем, когда мы нарушаем границы применимо­ сти такой карты .

Преобразование границ Что касается определения границ ОГРАНИЧЕННЫХ КОНТЕКСТОВ, то тут существует множество вариантов и неограниченное разнообразие ситуаций. Обычно в таких делах ищется баланс между некоторыми из перечисленных ниже факторов .

Преимущества больших контекстов:

различные пользовательские операции связаны между собой более плавно и есте­ • ственно, когда как можно больше разных объектов и операций охвачены одной унифицированной моделью;

легче понять одну связную модель, чем две разные и уровень отображения между •

–  –  –

общий язык стимулирует четкое взаимодействие в группе разработчиков .

Преимущества малЫХ контекстов:

снижаются издержки коммуникации между разработчиками;

• НЕПРЕРЫВНУЮ ИНТЕГРАЦИЮ (CONTINUOUS INTEGRATION) проще выполнять в ма­ • лых группах с небольшими базами кода;

в больших контекстах могут потребоваться более универсальные и абстрактные • модели, требующие редко встречающейся квалификации разработчиков;

небольшие модели могут обслуживать специальные потребности или соответст­ • вовать жаргону специализированных групп пользователей, а также узкоспециаль­ ных диалектов ЕДИНОГО ЯЗЫКА (UBIQU ITOUS LANGUAGE) .

Глубокая и тесная интеграция функций между разными ОГРАНИЧЕННЫМИ КОНТЕКСТАМИ на практике неуместна. Интеграция должна ограничиваться теми частями модели, которые можно строго сформулировать на языке другой модели, и даже такой уровень интеграции может потребовать значительных усилий. Это имеет смысл только тогда, когда интерфейс между двумя системами будет невелик по объему .

Принятие того, что нельзя изменить : контуры внешних систем Лучше всего начинать с простых решений. Некоторые подсистемы, очевидно, ока­ жутся за пределами всех ОГРАНИЧЕННЫХ КОНТЕКСТОВ проектируемой системы. Это, например, могут быть устаревшие системы, не подлежащие немедленной замене, а также внешние системы, которые предоставляют нужные услуги. Все это можно с самого нача­ ла распознать и отделить от своей собственной архитектуры .

Здесь следует быть осторожным в допущениях. Удобно считать, что каждая такая сис­ тема образует свой собственный ОГРАНИЧЕННЫЙ КОНТЕКСТ, но БОЛЫlIИНСТВО 13неllIНИХ 334 ЧАсть IV .

СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ систем слабо вписывается в это определение. Прежде всего ОГРАНИЧЕННЫЙ КОНТЕКСТ оп­ ределяется намерением унифицировать модель в определенных границах. Может быть, вы имеете право и возможность сопровождать старую систему, и тогда вы можете деклариро­ вать намерение. Или же группа, отвечающая за систему, хорошо скоординирована и следу­ ет неформальной процедуре НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ. Но это не следует считать само собой разумеющимся. Проверьте все сами, и если разработка не слишком хорошо скоорди­ нирована, то соблюдайте особую осторожность. В таких системах обычное дело - обнару­ жить семантические противоречия между разными их частями .

Взаимоотношения с внешними системами Здесь применимы три из описанных шаблонов. Прежде всего нужно рассмотреть ОТДЕЛЬНОЕ СУЩЕСТВОВАI-IИЕ (SEPARATE WAYS). Да, если бы интеграция не была нужна, эти системы вообще не затрагивались бы. Но нужно иметь полную уверенность. Может быть, будет достаточно предоставить пользователю легкий доступ к обеим системам?

Интеграция дорого стоит и отвлекает усилия, поэтому освободите ваш проект от этого бремени, насколько возможно .

Если интеграция действительно существенна, можно попытаться выбрать между двумя крайностями: КОНФОРМИСТОМ (CONFORMIST) или ПРЕДОХРАI-IИТЕЛЬНЫМ УРОВНЕМ (ANТI­ CORRUPTION LAYER). Вообrце, быть КОНФОРМИСТОМ не очень-то приятно. Творческие по­ рывы и выбор новых функциональных возможностей будут сильно ограничены. Проекти­ руя совершенно новую большую систему, вряд ли имеет смысл придерживаться модели ус­ таревшей или внешней систеIVIЫ (иначе почему мы создаем новую?). Однако модель старой системы может оказаться уместной для периферийных расширений большого программно­ го продукта, который в целом сохранит свои ведущие позиции. Примерами могут служить небольшие организационные программы для поддержки принятия решений, часто разра­ батываемые в среде Excel, и тому подобные простые утилиты. Если ваше приложение пред­ ставляет собой расширение для сущеСТВУIоrцей системы и должно иметь с ней большой ин­ терфейс, то трансляция между КОНТЕКСТАМИ легко может превзойти по объему все функ­ ции приложения. Но даже здесь есть пространство для качественного проектирования, пусть мы и находимся в ОГРАНИЧЕННОМ КОНТЕКСТЕ другой системы. Если в основе другой системы лежит достаточно отчетливая модель предметной области, вы можете улучшить свою программную реализацию, сделав эту модель более явной, чем она была в старой сис­ теме. Для этого просто нужно строго ей следовать. Если вы решите принять архитектуру КОНФОРМИСТА, это придется делать искренне, от всей души. Ограничьтесь созданием рас­ ширения-дополнения, не модифицируя существующую модель .

Если же функции проектируемой вами системы выходят за рамки простого расшире­ ния-дополнения к существующей системе, если интерфейс с другой системой мал по объему или же если другая система очень плохо спроектирована, то обязательно понадо­ бится свой собственный ОГРАНИЧЕНН Ы Й КОНТЕКСТ. А это означает, что придется по­ строить трансляционный уровень возможно, даже ПРЕДОХРАНИТЕЛЬНЫЙ YPOBEI-Ib (ANTICORRUPTION LAYER) .

Проектируемая система Под nроектuруемой системой подразумевается то программпое обеспечение, которое фактически разрабатывает вапrа группа. В этих пределах можно определить несколько ОГРАI-I ИЧЕННЫХ КОНТЕКСТОВ и внутри каждого выполнять НЕПРЕРЫВНУЮ ИНТЕГРАЦИЮ, чтобы поддерживать их унификацию. Но сколько контекстов нужно иметь? В каких отношениях они должны состоять? Ответы на эти вопросы не так тривиГЛАВА 14. ПОДДЕРЖАНИЕ ЦЕЛОСТНОСТИ МОДЕЛИ 335 альны, как в случае внешних систем, потому что здесь у нас больше свободы и контроля над ситуацией .

Можно поступить просто: ввести один ОГРАНИЧЕННЫЙ КОНТЕКСТ для всей проскти­ руемой системы. Это хороший вариант, например, для группы менее чем из десяти чело­ век, которая работает над тесно связанным набором функций .

По мере роста численности разработчиков НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ (CONTINUOUS INTEGRATION) становится все труднее (хотя я видел примеры ее поддержания и в довольно больших коллективах). Может быть, стоит подумать об ОБЩЕМ ЯДРЕ (SHARED KERNEL) и вынести относительно независимые наборы функций в отдельные КОНТЕКСТЫ, чтобы Hal каждым работало не более десяти человек. Если же все взаимоотношения между двумя та­ кими группами направлены в одну сторону, можно организовать отношения по типу ГРУПП

"ЗАКАЗЧИК -ПОСТАВЩИК" (CUSTOMER/SUPPLIER DEVELOPMENT TEAMS) .

Бывает, что образ мышления у двух групп столь различен, что в процессе моделиро­ вания они все время вступают в конфликт. Может быть, они на самом деле хотят разного от своих моделей. Может быть, у них разная подготовка и общие знания на эту тем у .

А может быть, так устроено руководство данным проектом. Если причину конфликта устранить никак нельзя или незачем, можно позволить двум моделям "вести" ОТДЕЛЬНОЕ СУЩЕСТВОВАНИЕ (SEPARATE WAYS). Если же интеграция необходима, то можно разработать трансляционный уровень и сопровождать его совместными усилия­ ми двух групп в качестве единственной точки НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ. Это совсем другое дело, чем интеграция с внешними системами, где обычно приходится присоеди ­ нять всю систему в неизменном виде через ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ (ANTICORRUPTION LAYER) и без особой поддержки с другой стороны .

В целом, на один ОГРАНИЧЕННЫЙ КОНТЕКСТ обычно приходится одна группа разра­ ботчиков. Одна группа может сопровождать несколько КОНТЕКСТОВ, но нескольким группам очень трудно (если вообще возможно) вместе работать над одним КОНТЕ КСТОМ .

Учет особых случаев отдельными моделями Различные группы в пределах одной области деятельности часто развивают CBOIO собственную узкоспециализированную терминологию. Локальные жаргоны расходятся и начинают отличаться друг от друга, оставаясь очень точными и приспособленны м и к решению проблем в своих подобластях. Чтобы изменить такие жаргоны (например, введя единый терминологический стандарт в какой-то отрасли), нужно разрешить про­ тиворечия, а для этого придется много поработать. и даже тогда новая терминологи я может оказаться не настолько удачной, как уже существующая, отлаженная версия .

Можно попробовать учесть специальные случаи в отдельных КОНТЕКСТАХ, позволив моделям "вести" ОТДЕЛЬНОЕ СУЩЕСТВОВАНИЕ, за исключением НЕПРЕРЫВНОЙ И НТЕГРАЦИИ трансляционных уровней. Вокруг таких моделей и специализированного жаргона, на котором они основаны, будут развиваться различные диалекты ЕДИНОГО ЯЗЫКА. Если у двух диалектов много общего, то, чтобы добиться нужной степени специа­ лизации и одновременно минимизировать затраты на трансляцию, можно воспользоваться ОБЩИМ ЯДРОМ ( SHARED KERNEL) .

Если интеграция не нужна или сравнительно ограничена, это позволяет продолжить использование собственной терминологии, избегая при этом порчи модели.

Имеются здесь и свои риски с издержками:

потеря общего языка ухудшает коммуникацию;

• интеграция требует дополнительных затрат;

–  –  –

ные модели одних и тех же процессов и объектов .

Но, возможно, самый большой риск состоит в том, чтобы отказаться от попыток из­ менений и оправдать любую узкоспециализированную, э кзотичеСКУIО модель. Зададимся вопросом: насколько необходимо перекроить данную KOHKpeTHYIO часть системы, для то­ го чтобы она решала особые задачи? Более того: насколько ценен и важен ЗlCаргон этой КО1-lкретной группы пользователей? Необходимо сопоставить преимущества независимой работы группы с рисками, связанными с трансляцией, и стараться рационализировать терминологические различия, в которых нет особого смысла .

Иногда возникает углубленная модель, которая может унифицировать различные языки и удовлетворить обе группы разработчиков. Но в том-то и подвох, что углубленнь[е модели возникают (если возникают) на поздних этапах разработки, в результате значительных уси­ лий и переработки знаний. Спланировать такую модель нельзя, можно только не упустить возможность, когда она возникает, изменить стратегию и выполнить рефакторинг .

Не забывайте, что там, где требования к интеграции велики, стоимость трансляции рез­ ко возрастает. Чтобы облегчить трансляцию, не прибегая к полной унификации, можно скоординировать усилия групп до некоторой степени - от точечных модификаций одного объекта со сложной трансляцией до введения ОБЩЕГО ЯДРА (SHARED KERNEL) .

установка системы Координирование финальной сборки и установки сложной системы - это одна из тех скучных задач, которые почти всегда сложнее, чем они кажутся. Выбор стратегии по­ строения ОГРАНИЧЕННОГО КОНТЕКСТА оказывает на установку свое влияние. Например, когда новые версии приложений устанавливаIОТСЯ ГРУППАМИ "ЗАКАЗЧИК-ПОСТАВIЦИК " (CUSTOMER/SUPPLIER TEAMS), им приходится координироваться между собой, чтобы ус­ тановить совместно протестированные версии. Тут учитывается и код, и перенос данных .

Ч то касается распределенной системы, то в ней полезно разрабатывать трансляционные уровни между КОНТЕКСТАМИ совместно, в рамках одного процесса, чтобы не lIЛОДИТЬ па­ раллельно существующих разных версий .

Даже установка компонентов одного и того же О ГРАНИЧЕННОГО КОНТЕКСТА может представлять трудности, если перенос данных занимает время или если распределенные системы нельзя обновить одновременно, отчего начинают параллельно сосуществовать две версии кода и данных .

В зависимости от среды и технологии установки приложения возникает множество разных технических соображений. Наиболее критические места вам укажут взаимосвязи между ОГРАНИЧЕННЫМИ КОНТЕКСТАМИ - особенно выделяются в этом плане трансля­ ционные интерфейсы .

Реализуемость плана установки имеет обратную связь с проведением границ между КОНТЕКСТАМИ. Если два КОНТЕКСТА соединены трансляционным уровнем, то один КОНТЕКСТ можно обновить так, чтобы новый трансляционный уровень обеспечивал тот же интерфейс ко второму КОНТЕКСТУ. Наличие ОБЩЕГО ЯДРА (SHARED KERNEL) накла­ дывает гораздо более жесткие требования к координации, и не только при разработке, но и при установке. Упростить жизнь может ОТДЕЛЬНОЕ СУЩЕСТВОВАНИЕ .

Компромиссы Подытожим высказанные выше рекомендации. Существует целый ряд стратегий унификации или интеграции моделей. В целом, следует искать компромисс между пре­ имуществами интеграции функций в одно целое и необходимостью дополнительной коГЛАВА 14. П ОДДЕРЖАНИЕ ЦЕЛОСТНОСТИ МОДЕЛИ 337 ординации и коммуникации. На одной чаше весов - независимость действий, на дру­ гой - единообразие коммуникации. Чем более полная унификация требуется, тем боль­ ше контроля следует иметь над архитектурой всех учаСТВУIОЩИХ в ней подсистем .

–  –  –

равнительная характеристика шаблонов взаuмооmношенuit.;иеJ/сду КОIIТЕКСТАМИ Рис. 14. 13. С Если проект уже в работе Бывает, что мы не начинаем новый нроект, а используем у)ке суu(ествующий, нахо­ дящийся в работе, и пытаемся его усовершенствовать. В JTOM случае первый шаг ---- это определить ОГРАНИЧЕf-IНЫЕ КОНТЕКСТЫ ( BOUNDED CONTEXTS) в соответствии с теку­ щей реальностыо. Это критический момент. Чтобы быть эффективным инструментом, КАРТА КОНТЕКСТОВ (CONTEXT МАР) должна отражать реальную практику разработчиков, а не идеальную организацию, нарисованную по вышеописанным рекомендациям .

После того как определены реальные, действуюrцие в настоящий момент ОГРАНИЧЕННЫЕ KOI ITEKCTbI и описаны взаимоотношения между ними, следующий шаг - это построить практику разработчиков как можно теснее вокруг текущей орга1-luзации. Улучшайте НЕПРЕРЫВНУЮ ИНТЕГРАЦИIО (CONTINUOUS INTEGRATION) в пределах КО НТЕКСТОВ. Выдели­ те весь неупорядоченный трансляционный код в ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ (ANTI­ CORRUPTION LAYER). Дайте имена ОГРАНИЧЕННЫМ ко] [ТЕКСТАМ и обязательно включите их в ЕДvIНЫЙ язык проекта .

Вот теперь вы готовы рассматривать изменения граНИЦ и взаимосвязей. Эти изменения будут естественным образом основаны на тех же припципах, которые уже описаны здесь для новых проектов. Но их придется разбить на много мелких кусочков, выбирая их праг­ матически с точки зрения максимальной отдачи при минимуме усилий и разрушений .

В следующем разделе рассказывается, как именно нужно изменять границы КОН­ ТЕКСТА, если уж вы решили это сделать .

338 ЧАсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Преобразования Как и другие аспекты моделирования и проектирования, ре ш ения насчет ОГРАНИ­ ЧЕНI IЫХ КОНТЕКСТОВ (BOUNDED CONTEXTS) не являются окончательными и беспово­ ротными. Неизбежно возникают ситуации, в которых приходится изменять первона­ чальное реш ение насчет границ и взаимоотношений ОГРАНИЧЕННЫХ КОНТЕКСТОВ. В це­ лом, разбивать КОНТЕКСТЫ на части довольно легко, а вот объединять их или изменять взаимоотношения между ними может оказаться сложнее. Я опишу несколько характер­ ных трудных, но важных изменений. Такие преобразования обычно слишком велики, чтобы проделать их за один рефакторинг или даже за одну итерацию проекта. Поэтому я составил поэтапные планы преобразований, в которых они представлены как серии вполне управляемых модификаций. Это, конечно, всего лишь рекомендации, которые н ужно приспособить к конкретным обстоятельствам .

Слияние контекстов : от отдельного существования к общему ядру Расходы на траНСЛЯЦИIО велики. Дублирование - слишком очевидная мера. Есть много соображений в пользу слияния ОГРАНИЧЕННЫХ КОНТЕКСТОВ. НО делать это труд­ но. Еще не поздно, но терпение понадобится .

Даже если ваша конечная цель - полное слияние в один ОГРАНИЧЕННЫЙ КОНТЕКСТ пу­ тем НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ, начинайте с перехода к ОБЩЕМУ ЯДРУ (SHARED KERNEL) .

Оцените начальную ситуаЦИIО. Убедитесь, что два КОНТЕКСТА действительно еди­ 1 .

ны по смыслу, прежде чем начинать их формальную унификацию .

Подготовьте процесс. Необходимо выработать порядок работы с общим кодом 2 .

и установить правила именования модулей. Код ОБЩЕГО ЯДРА должен подвергать­ ся интеграции как минимум раз в неделю. Для него должен существовать набор тестов. Создайте его еще до того, как писать общий код. ( Вначале он будет пустым, так что пройти такие тесты - не проблема! ) Выберите для начала неБОЛЬШУIО подобласть нечто дублирующееся в обоих 3 .

КОНТЕКСТАХ, но не входящее в СМЫСЛОВОЕ ЯДРО (CORE DOMAIN) предметной об­ ласти. Первое слияние имеет своей целью только "обкатать" процедуру, так что для него лучше выбрать нечто простое, сравнительно отдельное и некритичное. Изучи­ те уже существующие интеграции и трансляции. Выбор чего-то уже транслируемо­ го хорош тем, что транслируемость проверена. А по итогам работы трансляцион­ ный уровень еще уменьшится в размерах .

В этот момент у вас будет две модели, относящиеся к одной и той же подобласти. Су­ ществует три основных подхода к слиянию. Можно взять одну модель и выполнить ре­ факторинг другого КОНТЕКСТА, чтобы привести его к совместимому виду. Это решение можно принимать "оптом", задавшись целыо систематически заменить модель одного КОНТЕКСТА и сохранить при этом связность модели, разрабатывавшейся как одно целое .

А можно действовать постепенно, и в результате, возможно, придти к оптимальной ком­ бинации двух вариантов (но придется постараться, чтобы это не была хаотическая куча) .

Третий вариант - это найти новую модель, предположительно более глубокую, чем любая из исходных, которая бы смогла взять на себя обязанности обеих сторон .

Сформировать группу из двух-трех разработчиков из обеих групп, для выработки 4 .

общей модели подобласти. Независимо от того, каково происхождение модели, она должна быть проработана во всех подробностях. Это означает, в том числе, опреде­ ление синонимов и установку соответствия между терминами, которые еще не

ГЛАВА 14. ПОДДЕРЖАНИЕ ЦЕЛОСТНОСТИ МОДЕЛИ

транслировались. Объединенная группа набросает и ориентировочный набор тес­ тов дл модели .

5. Разработчики из каждой группы берутся реализовать модель ( или адаптировать сущеСТВУI0ЩИЙ код, поступаIОЩИЙ в совместное пользование), проработать детали и довести до рабочего состояния. Если они сталкиваются с проблемами в модели, то снова собирают группу (см. п. 4) и сами участвуют в необходимой доработке по­ нятий .

Разработчики каждой из групп берутся за задачу интегрирования с новым ОБЩИМ 6 .

ЯДРОlVI (SHARED KERNEL) .

Убрать трансляции, которые больше не нужны .

7 .

На :этом этапе ОБЩЕЕ ЯДРО ( SHARED KERNEL) будет еще очень маленьким; к нему бу ­ дет прилагаться процедура сопровождения. На послеДУIОЩИХ итерациях проекта повто­ ряйте пп. 3-7 для расширения ядра. По мере закрепления процедур и приобретения уве­ ренности в себе можно выбирать более сложные подобласти, а то и сразу несколько за один раз или же подобласти из СМЫСЛОВОГО ЯДРА (CORE DOMAIN) .

Сделаем одно замечание. Приступая к более специфичным для предметной области частям модели, можно встретить случаи, когда две модели построены в соответствии со специальным жаргоном разных сообществ пользователей. Разумно будет подождать с ВКJIlочением таких моделей в ОБЩЕЕ ЯДРО (SHARED KERNEL), если к этому моменту н е произошел скачок к углубленной модели, отчего должен БыIл появиться язык, способный заменить оба с пециализированных жаргона. Особенность ОБlЦЕГО ЯДРА состоит в том, что можно пользоваться преимуществами НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ, притом сохра­ няя и некоторые преимущества ОТДЕЛЬНОГО СУ IЦЕСТВОВАНИЯ .

ДЛЯ слияния в одно ОБЩЕЕ ЯДРО (SHARED KERNEI..) существуют определен н ые правила .

Прежде чем двигаться дальше, следует рассмотреть одну альтернативу, решающую некото­ рыIe задачи, ради которых и задумывается это преобразование. Если одна из двух моделей однозначно предпочтительнее, подумайте, не стоит ли перейти на пее без интеграции. Вме­ сто организации общих подобластей просто передайте все обязанности, относящиеся к этим подобластям, из одного КОНТЕКСТА в другой .

Для этого потребуется рефакторинг приложений к модели из более предпочитаемого КОНТЕКСТА и разные мелкие усовершен­ ствования, требуемые моделью. Итак, и избыточность устранена, и затрат на интеграЦИIО никаких. Потенциально (хотя и не обязательно) предпочитаемый КОНТЕКСТ может вообlЦС вытеснить другой, и получится тот же эффект, что при слиянии. На переходном этапе (который может длиться неопределенно долго) здесь будут иметь место обычные преим у ­ щества и недостатки ОТДЕЛЬНОГО СУЩЕСТВОВАНИЯ, которые нужно будет сравнить с пре­ ИМУlдествами и недостатками ОБЩЕГО ЯДРА (SHARED KERNEL) .

Слияние контекстов : от общего ядра к непрерывной интеграции По мере того как ваПIе ОБЩЕЕ ЯДРО ( SHARED KERNEL) расширяется, вас может увлечь мысль о преиl\tl уществах полной унификации двух КОНТЕКСТОВ. НО дело здесь не только в устранении различий между моделями. Придется изменять структуру рабочих групп И, в конце концов, даже язык, на котором говорят разработчики .

Начните с подготовки сотрудников и групп .

Убедитесь, что все процедуры, необходимые дЛЯ НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ 1 .

( совместное владение кодом, частая интеграция и т.п.), поручены отдельно каждой группе. ll риведите в соответствие интеграционные процедуры в обеих группах, чтобы все делали одно и то же одним и тем же образом .

340 Ч Асть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Начните ЦИрКУЛЯЦИIО разработчиков между группами. Это создаст группу ЛIодей, 2 .

понимающих обе модели, и положит начало объединению двух групп .

Об ъявите отдельную дистилляцию каждой модели (см. главу 15) .

з .

На этом этапе уже должно хватить уверенности в себе для того, чтобы начать пере­ 4 .

ливать СМЫСЛОВОЕ ЯДРО (CORE DOMAIN) предметной области в ОБЩЕЕ ЯДРО (SHARED KERNEL). На это может уйти несколько итераций. Иногда бывают нужны временные трансляционные уровни между новыми общими частями и частями, еще не ПОСТУПИВIIlИМИ в общий доступ. "ВЗЯВIIlИСЬ" за СМЫСЛОВОЕ ЯДРО, надо ра­ ботать быстро. Это очень затратный этап, где встречается много ОIIlибок, и его нужно побыстрее пройти в приоритетном порядке, даже отложив разработку ново­ го. Но не следует брать на себя СЛИIIlКОМ много .

Для слияния моделей СМЫСЛОВОГО ЯДРА есть несколько способов. Можно придер­ живаться одной модели, делаю другую совместимой с ней. Или же можно создать новую модель подобласти и приспособить оба КОНТЕКСТА к ее использованию. Берегитесь слу­ чая, когда две модели специально спроектированы для удовлетворения разных нужд пользователя. Вам могут понадобиться специализированные возможности обеих исход­ ных моделей. Для этого можно разработать углубленную модель, которая бы превзошла обе исходные модели. Разработка углубленной унифицированной модели - дело очень сложное, но если вы поставили себе задачу полного слияния двух КОНТЕКСТОВ, то боль­ ше не можете себе позволить иметь много разных диалектов. Но зато вас ждет награда в виде четкой, ясной интеграции получившейся модели и кода. Убедитесь, что эти пре­ имущества не имеют свою оборотную сторону в виде невозможности ДОЛЫIlе соответст­ вовать специальным потребностям пользователей .

5. По мере роста ОБЩЕГО ЯДРА (SHARED KERNEL) увеличивайте частоту процедур ин­ теграции до ежедневной, а там и дО НЕПРЕРЫВНОЙ ИI-IТЕГРАЦИИ .

По мере того как ОБЩЕЕ ЯДРО приближается к точке, в которой оно ВКЛIОЧИТ В себя 6 .

оба бывших ОГРАНИЧЕI-IНЫХ КОНТЕКСТА, вы будете оказываться то среди одной большой группы разработчиков, то в двух маленьких с общей базой кода, которую они непрерывно интеГРИРУIОТ. И между этими группами постоянно будут сновать туда-сюда сотрудники .

Вытеснение устаревшей системы Все xopolIlee когда-нибудь кончается - и срок службы старого программного обеспе­ чения тоже. Но конец приходит по-разному. Старые системы могут быть так переплете­ ны с предметной областью и другими системами, что извлечение их 01 туда может длить­ ся годы. К счастью, совсем не обязательно извлекать его сразу и мгновенно .

Я лишь набросаю здесь общую схему, так как всех вариантов действий слишком мно­ го, чтобы их изложить. Я ОПИIIlУ обычный случай: старая система, используемая еже­ дневно в какой-то отрасли деятельности, недавно дополнена горсткой более современ­ ных систем, вступающих с нею в контакт через ПРЕДОХРАНИТЕЛЫ-IЫЙ YPOBEI-Ib (ANTI­ CORRUPTION LAYER) .

Один из первых шагов должен состоять в том, чтобы выработать стратегию тестиро­ вания. Для новых функций новой системы нужно написать автоматизированные мо­ дульные тесты. Но вытеснение старой системы требует своих, специфических тестов .

Некоторые организации в течение какого-то периода времени параллельно запускаIОТ старые и новые тесты .

На каждой итерации этого процесса следует выполнить следующее .

–  –  –

И ногда бывает необходимо потратить несколько итераций на написание эквивалент­ ных функций для модуля старой системы, который будет вскоре выБРОlпен. Но новые (рункции все равно следует планировать в форме небольших l'vlодулей, которые ПИIПУТСЯ за одну итерацию, а вот для своей установки требуют несколько .

Установка и развертывание приложений - это СЛИIПКОМ многообразная деятель­ пость, чтобы здесь можно было рассмотреть все известные базы кода. Было бы хорошо, если бы все малые, постепенные изменения можно было бы так же оперативно показы­ вать в конечном продукте. Но на практике обычно организовывают выпуск значительно отличаIОЩИХСЯ друг от друга версий. Пользователей нужно обучать работе с новыми программами. Иногда нужно закончить период параллельной разработки. Следует про­ работать много логистических проблем .

Как только программное обеспечение установлено и заработало, выполните такие действия .

5. Определите, какие части IIРЕДОХРАНИТЕЛЬНОГО УРОВНЯ не являются необход и ­ мыми, и удалите их .

Попробуйте "вырезать" уже неиспользуемые модули старой системы, хотя это мо­ 6 .

жет оказаться ни к чему. По иронии, чем лучше спроектирована старая система, тем легче будет от нее избавиться. А вот плохо спроектированные программы тя­ жело демонтировать по малеНЬКОl'vIУ кусочку. Может быть, стоит просто игнориро­ вать неиспользуемые части программы, пока последние остатки не будут ВЫЧИlце­ ны, и можно будет отключить все сразу .

Повторяйте процесс снова и снова. В ходе этого старая система должна все меньше и меньше вовлекаться в работу; со временем станет виден свет в конце туннеля, и ее можно будет отключить совсем. Между тем ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ будет то уменьшать­ ся, то разбухать по мере того, как различные сочетания связей будут увеличивать или умеиыuать взаимозависимость между системами. При прочих равных условиях нужно, ко­ нечно, перенести первыми те функции, которые уменыпаIОТ ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ. НО могут выйти на первый план и другие факторы. Тогда придется временно ми­ риться с самыми неожиданными трансляциями .

От открытого протокола к общедоступному языку ВЬ{ интегрируетесь с другими системами через набор открытых протоколов (как OPEN-HOST SERVICES), но по мере того, как HOBbIe системы· запрашивают доступ к ваlll(Й, бремя ее сопровождения становится все тяжелее, и понять все взаимодействия становит­ ся все труднее. Необходимо формализовать отношения между системами через О Б IЦЕ­

ДОСТУПНЫЙ ЯЗЫК ( PUBLISHED LANGUAGE) .

Б03Если в отрасли есть единый стандартный язык обмена данными, оцените его 1 .

мо)кности и используйте его, если это ДОПУСТИl'vIО .

Если никакого общего стандарта или опубликованного языка нет, начните с четко­ 2 .

го выделения СМЫСЛОВОГО ЯДРА ( CORE DOMAIN) системы, которая будет служить сервером открытого протокола (см. главу 15) .

ЧАсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Используйте СМЫСЛОВОЕ ЯДРО как основу для языка коммуникации, подключив 3 .

стандартную парадигму обмена данными наподобие XML, если это возможно .

Сделайте новый язык общедоступным (опубликуйте его) как минимум для всех, 4 .

кто с вами взаимодействует .

5. Если важна архитектура новой системы, опубликуйте и ее тоже .

Постройте трансляционны·е уровни для каждой ПОДКЛlочающейся к вам системы .

6 .

Переключитесь на HOBYIO систему .

7 .

На этом этапе дополнительные систеlVlЫ должны получить возможность подключать­ ся с минималы-IыIии препятствиями .

Помните, что ОБIЦЕДОСТУПНЫЙ язык должен быть стабильным, но при этом вам нужна свобода для изменения lVlодели своего приложения в ходе постоянного рефакто­ ринга. Поэтому не оmождеmсmвляйmе между собой язы1{ обмена информацией и модель nршzожения. Если поддерживать их достаточно близкими, то затраты на трансляцию бу­ дут невелики, и приложение можно будет сделать КОI-IФОРМИСТОМ. НО оставьте за со­ бой право нарастить трансляционный уровень и увести его в сторону, если это окажется более вытодно .

Руководители проектов должны определять ОГРАНИЧЕННЫЕ КОНТЕКСТЫ (BOUNDED CONTEXTS) на основе требований к функциональной интеграции и взаИМООТНОIIIений меж­ ду группами разработчиков. Как только ОГРАНИЧЕННЫЕ КОНТЕКСТЫ и КАРТА КОНТЕКСТОВ (CONTEXT МАР) явно определены и строго соблюдаются, можно считать, что логическая не­ противоречивость и самосогласованность находится под заIЦИТОЙ. По крайней мере, про­ блемыI КОМlVlуникации будут лежать на поверхности, и с ними можно будет работать .

Однако иногда контекстаlVIИ моделей, ограниченными сознательно или естественным путем, злоупотребляют для решения проблем, отличных от логической несогласованности внутри системы. Разработчики могут обнаружить, что lVlодель большого КОНТЕКСТА СЛИlII­ ком сложна для понимания или анализа ее в целом. То ли HalVlepeHHo, то ли случайно это часто приводит к разбиению КОНТЕКСТА на более мелкие части, поддающиеся осмысле­ НИIО. Такая фрагментация отбирает часть возможностей. Поэтому стоит тщательно проана­ лизировать реlIIение об организации БОЛЫIIОЙ lVlодели в.широком КОНТЕКСТЕ. И если с ор­ ганизационной или политической точки зрения невозможно удержать КОНТЕКСТ в цело­ сти, если он действительно распадается, тогда нужно перерисовать КАРТУ КОНТЕКСТОВ и определить такие границы, которые можно будет соБЛlодать. Но если БОЛЫIIОЙ KOI-ITEKCT соответствует естественным потребностям интеграции и если он кажется обоснованным независимо от сложности самой модели, тогда разбиение такого КОНТЕКСТА уже не будет ХОрОIIIИМ решением .

Есть другие способы сделать большие модели управляемыми, которые следует по­ пробовать, прежде чем идти на такие жертвы. В следующих двух главах рассматривается вопрос об " укрощении сложности" в болыпих моделях путем применения двух стратеги­ ческих принципов: дистилляции и крупномасштабной структуры .

ГЛАВА 14. ПОДДЕРЖАНИЕ ЦЕЛОСТНОСТИ МОДЕЛИ

ГЛАВА 1 5

–  –  –

Эти четыре уравнения, вместе с определениями nонятий и лежащим в их ос­ нове математическим аппаратом, описывают всю классическую теорию электромагllетизма XIX в .

К ак сосредоточиться на главной проблеl\lIе и не утонуть в море второстепенных деталей? МНОГОУРОВНЕВАЯ АРХИТЕКТУРА (LAYERED ARCHITECTURE) позволяет отделить понятия предметной области от технической части, винтиков и шестеренок программной системы. Но в болыпих системах даже изолированная предметная область может быть сложной до неуправляеl\lIОСТИ .

это процесс разделения компонентов смеси с целыо выIеленияя осДистилляция новного веlцества в такой фОРl\lIе, которая делает его более ценным и полеЗНЫl\lI. Построе­ ние модели есть дистилляция знания. С каждым шагом углубляющего рсфакторинга мы абстрагируем какой-то КЛIочевой аспект знаний и приоритетов из предметной области .

А в этой главе, отступив на rпаг назад и придерживаясь соотвеТСТВУЮIдей стратегии, по­ говорим о дистилляции всей l\IIодели предметной области в целом и о том, как набрасы­ вать Cal\lIbIe IIIирокие мазки будуrцей картины .

Как это бывает нередко в случае химической дистилляции, выделяемые ею побочные продукты тоже становятся более ценными в результате этого процесса. Это верно для

ЕСТЕСТВЕI-П-IЫХ ПОДОБJIАСТЕЙ (GENERIC SUBDOMAINS) и СВЯЗНЫХ МЕХАl IИЗМОВ (СОНЕ­

SIVE MECHANISMS). НО все-таки основные усилия вызваны желанием выделить один кон­ кретный, особо ценный компонент тот, который отличает нашу программу от других и придает ей ценность, т.е. СМЫСЛОВОЕ ЯДРО предметной области (CORE DOMAIN) .

Стратегическая дистилляция модели предметной области выполняет сразу несколько функций .

и Помогает всем разработчикам нонять архитектуру системы в целом взаимосвязь 1 .

между ее частями .

Облегчает процесс КОl'vIмуникации, выделяя ключеВУIО l'vlодель обозримой величины, которая включается в ЕДИНЫЙ ЯЗЫК (UBIQUITOUS LANGUAGE) .

Задает направление рефакторинга .

3 .

Фокусирует внимание на тех частях модели, которые имеют наиБОЛЬШУIО ценность .

4 .

5. Помогает определиться с субподрядами (аУТСОРСИНГОl'vI), использованиеl'vI готовых компонентов, распределением задач .

этой главе излагается систематический подход к проведению стратегической дис­ В тилляции СМЫСЛОВОГО ЯДРА предметной области (CORE DOMAIN). Будет рассказано, как распространить правильное восприятие дистилляции на всю группу разработчиков и создать язык, на котором можно обсуждать CBOIO работу .

–  –  –

Как садовник обрезает на деревьях лишнее, чтобы дать возможность расти основным ветвям, так и мы собираемся применить целый набор приеl'vIОВ, чтобы отсечь от модели все несущественное и сосредоточить внимание на самом значимом.. .

–  –  –

При проектировании большой программной системы нужно учесть так много раз­ н ых компонентов, причем сложных и совершенно необходимы х дл я успеха дела, что с ущность модел и предметной обл асти - главного и настоящего делового актив а - мо ­ жет затуманиться и пропасть из виду .

Систеl'ЛУ, которую трудно понять, трудно и менять. Очень сложно предвидеть, каким будет эффект внесенных ИЗl'vlенениЙ. Разработчик, "выIlедшийй за пределы" знакомой ему части приложения, тут же теряется. ( В частности, так бывает, I{огда в группу приходят новые люди, но даже и постоянны·й ее участник будет испытывать трудности, если не сделать код выразительным и организованны·м.) Это вы·нуждает разработчиков специа­ лизироваться. Когда они начинаIОТ ограничиваться работой только над конкретными модуляl'vIИ, передача знаний снова ухудшается. Такое жесткое разбиение меlпает инте­ грации системы и гибкому распределению работы. Когда lIрограМl\1ИСТ не знает, что те или иные алгоритмы уже реализованы в другом месте, возникает дублирование, и систе­ ма снова усложняется .

Таковы некоторые последствия малопонятной архитектуры. Но есть и другой, равно серьезный риск - потерять из В I lДУ обlЦУЮ картину предметной области .

В с уровой реальности не все части архитектур ы совершенствуются одинаково .

Следует расставлять приоритет ы. Чтобы сдел ать модель предметно й обл асти ценн ым активом, глав ное СМ Ы СЛОВОЕ ЯДРО модели дол жно бы ть отшл ифовано до мелочей ипол ностью задействовано в реализации функций программ ы. Но редко встречаю­ щиеся программист ы -про фессионалы тяготеют, скорее, к технической инфраструкту­ и р е или четко поста вленн ым задачам из предметной области, котор ые можно понять без специальных знаний о ней .

Такие части системы представляют интерес для специалистов-теоретиков програм­ мирования. Считается, что на их основе XOPOIIJO строить базу переНОСИl'vIЫХ профессио­ нальных знаний и подбирать ИЛЛIостративный материал. Специализированное ядро, т.е .

та часть модели, которая отличает приложение от всех остальных и делает его цеННЫl'v1 активом, обычно собирают в одно целое с другими чаСТЯl'vIИ программисты более низкой квалификации. Совместно с аДl'vIинистраторами баз данных они создаIОТ структуру базы для приложения, а затем програМl'vПlРУЮТ одну функцию за другой, не заботясь о том, чтобы воспользоваться концептуальными преПМУIlхествами модели .

ГЛАВА 15. Дистилляция 347 Плохая архитектура или реализация этой части программы ведет к тому, что ее поль­ зователям всегда субъективно "чего-то не хватает", пусть даже техническая инфраструк­ тура работает прекрасно, а вспомогательные возможности реализованы на высшеl'vI уров­ не .

Эта коварная проблема "подкрадывается" тогда, когда в проекте нет четкого видения всей архитектуры в целом и относительной ценности разных ее частей .

Один из наиболее успешных проектов, в которых я работал, вначале тоже страдал от этого синдрома. Цель проекта состояла в разработке очень сложной систеl'vIЫ управления синдицированными кредитами. БОЛЫIIИНСТВО квалифицированных сотрудников, не напря­ гаясь, работали над интерфейсом обмена сообщениями и УРОВНЯl'vIИ отображения баз дан­ ных, тогда как прикладная модель находилась "в руках" новичков объектных технологий .

Единственным исключением из этой практики был опытный объектно-ориентированный разработчик, работавший над проблемой из предметной области. Он придумал способ добав­ лять КОl'vIментарии к любому из долговременных объектов предметной области. Эти коммен­ тарии l'vIОЖНО было организовывать таким образом, чтобы участники процесса видели пись­ менно зафиксированное обоснование своих прошлых решений. Он же разработал ИЗЯIЦНЫЙ пользовательский интерфейс, который предоставил интуитивно-удобный доступ к гибким ВОЗl'vIОЖНОСТЯМ модели комментариев .

Эти возможности были полезны и XOPOIIIO спроектированы. Они ВОlIIЛИ в оконча­ тельный продукт. Но, к сожалению, это были периферийные ВОЗl'vIОЖНОСТИ. Талантливый програl'vIМИСТ смоделировал интересный и оригинальный способ комментирования ре­ Iпений, качественно реализовал его и вложил в руки пользователя. Тем временем один некомпетентный программист превращал критический для функционирования прило­ жения "кредитный" модуль в "непонятное месиво", которое чуть не сгубило проект .

В процессе планирования следует направлять ресурсы на самые "критические участ­ ки" модели и архитектуры. А для этого такие участки в ходе планирования и разработки должен видеть каждый участник .

Части модели, которые l'vIОЖНО четко выделить как основные для выполнения главной задачи приложения, образуют ее СМЫСЛОВОЕ ЯДРО (CORE DOMAIN). Именно в СМЫСЛО­ ВОМ ЯДРЕ ваша система производит свой основной "добавочный продукт" .

"У парьте " модель до минимума. Найдите ее СМЫСЛОВОЕ ЯДРО и сделайте так, что­ бы его можно б ыло легко отличить от массы вспомогательных частей модели и кода .

Четко, рельефно выделите самые ценные и специализированные понятия. ЯДРО долж­

–  –  –

многих решений. Много усилий уходит на то, чтоБыI сделать ЯДРО оригинальным, вы­ пукло выделить его, при ЭТОl'vI оставляя остальную часть архитектуры настолько общей и стандартной, насколько это удобно практически. Если существует аспект архитектуры, который необходимо хранить в секрете как конкурентное преимущество, то это именно СМЫСЛОВОЕ ЯДРО. Нет необходимости скрывать остальное. И если встает вопрос о вы­ боре (В силу ограниченности времени) между двумя разными процедурами рефакторин­ га, надо выбирать ту, которая активнее воздействует на СМЫСЛОВОЕ ЯДРО .

* * * 348 ЧАсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Шаблоны, приведенные в этой главе, помогаIОТ лучше увидеть, использовать и моди­ фицировать СМЫСЛОВОЕ ядро .

Выбор ядра Сейчас в поле нашего зрения находятся те части модели, которые, собственно, и пред­ ставляют деятельность в преДl'vlетной области, реIllение поставленных в ней задач .

Выбор СМЫСЛОВОГО ЯДРА (CORE DOMAIN) зависит от точки зрения на проблему. На­ пример, для многих приложений требуется самая общая модель денег, в которой можно представлять различные ваЛIОТЫ, их обменны·Й курс, всевозможные расчеты по обмену валют .

С другой стороны, програl'vIма для валIОТНЫХ торгов нуждается в более сложной и проработанной модели денег, которая и составит СМЫСЛОВОЕ ЯДРО. Но даже в таком случае часть модели денег может по-прежнему носить самый обlЦИЙ характер. По мере того как с опытом углубляется понимание преДl'vlетной области, можно продолжать и процесс дистилляции, отделяя оБIдие понятия модели денег и оставляя в СМЫСЛОВОМ ЯДРЕ только узкоспециализированные аспекты .

В программе для обслуживания транспортных перевозок и доставки грузов ЯДРО мо­ жет включать модель консолидации грузов для их общей доставки, модель передачи юридической ответственности при переходе контейнеров из рук в руки или же модель перемещения контейнера на разных видах транспорта по определенному марIПрУТУ в пункт назначения. СМЫСЛОВОЕ ЯДРО в приложении для инвестиционного банка могло бы содержать модель синдикации средств между инвестораl'vIИ и получателями .

СМЫСЛОВОЕ ЯДРО, для другого - всего липrь об­ То, что для одного приложения IЦИЙ вспомогательный компонент. Тем не менее в пределах одного проскта, а обычно и в пределах одной компании можно определить единое СМЫСЛОВОЕ ЯДРО. Как и любая другая часть архитектуры, СМЫСЛОВОЕ ЯДРО должно эволюционировать, развиваться итерационно. Важность того или иного набора взаИМООТНОlпений не всегда ясна с перво­ го взгляда. Объ екты, которые вначале казались безусловно центраЛЬНЫl'vIИ, в конце кон­ цов могут оказаться не более чем вспомогатеЛЬНЫl'vIИ .

В последующих разделах, особенно разделе, посвященном НЕСПЕЦИАЛИЗИРОВАl IlIЫМ ПОДОБЛАСТЯМ (GENERIC SUBDOMAINS), будут даны более подробные реКОl'vlендации для принятия таких решений .

Как распределить работу Наиболее технически грамотные программисты-участники проекта, как правило, не­ много знаIОТ о предметной области. Поэтому они приносят пользы меньше, чем могли бы, а заКОНОl'vlерная тенденция "ставить" их в связи с этим на ВСПОl'vlогательные компонен­ ты создает порочный круг: из-за недостатка знаний таких программистов не привлекают именно к той работе, которая дала бы им эти знания .

Этот круг очень важно разорвать, собрав такую группу разработчиков, в которой со­ шлись бы и сильные программисты, мыслящие долговременными категориями и заинтере­ сованные в накоплении знаний, и один или несколько специалистов в предметной области, которые профессионально владеют прикладной проблеl'vlатикоЙ. Проектирование архитек­ туры предметной области - это интересная и технически сло)кная работа, если подходить к ней серьезно. И программистов, которые Иl'vlенно так к ней относятся, найти несложно .

Обычно для конкретной работы по ностроению СМЫСЛОВОГО ЯДРА нерационально нанимать на короткое время постороннего проектировщика архитектуры. Группе неоБХОДИl'vIО накопить знания о предметной области, а временный сотрудник - это "бреIIIЬ" в обороне. С другой стороны, если взять специалиста на роль преподавателя, наставника, ГЛАВА 15. Дистилляция консультанта, то от него может быть очень много пользы: он поможет группе развить навыки архитектурного проектирования в данной предметной области и облегчит им работу со сложными принципами, которыми члены группы могут и не владеть .

По аналогичным причинам есть основания сомневаться, что СМЫСЛОВОЕ ЯДРО можно просто купить. Так, были предприняты болыпие усилия по созданию специализированных отраслевых сред моделирования. Наиболее заметные результаты этих усилий - разрабо­ танная гигантом полупроводниковой индустрии концерном SEMATECH среда CIM дЛЯ ав­ томатизации производства полупроводников, а также среды San Francisco от IБМ дЛЯ самых разных приложениЙ. Хотя сама идея заманчива, полученные результаты пока неубедительны, если не считать их применения в виде ОБЩЕДОСТУПНЫХ ЯЗЫКОВ для облегчения обмена данными (см. главу 14). В книге [ 10] дается обзор текущего состояния дел. Но по мере разви­ тия данной сферы могут появиться и более "работоспособные" среды моделирования .

При всем этом существует и более веская причина относиться к таким средам с осто­ рожностью. Дело в том, что ценность специализированной про граммы тем выIе,' чем больше у нее контроля над СМЫСЛОВЫМ ЯДРОМ. Хорошо спроектированная среда моде­ лирования предоставляет пользователю абстракции высокого уровня, которые можно специализировать для конкретных задач. Благодаря ей пользователь не должен зани­ маться разработкой самых общих частей приложения и может сосредоточиться на СМЫСЛОВОМ ЯДРЕ. Но если среда накладывает более жесткие ограничения, то возможна одна из трех ситуаций и, соответственно, один из трех вариантов действий .

Теряется одно из существенных преИl\lIуществ программы. Тогда следует отказать­ 1 .

ся от использования "стеСНЯIощей движения" среды· моделирования при проекти­ ровании СМЫСЛОВОГО ЯДРА .

Область, обслуживаемая средой, не является настолько ключевой, как могло пока­ 2 .

заться сначала. Тогда следует перенести границы СМЫСЛОВОГО ЯДРА так, чтобы они охватывали действительно знаЧИl\lIУЮ и оригинальную часть модели .

СМЫСЛОВОМ ЯДРЕ нет никаких специальных возможностей. Тогда следует по­

3. Б думать о более простом и менее затратном решении, например, приобретении гото­ вого приложения и интегрировании его со своим собственным .

Так или иначе, для разработки оригинального программного продукта не обойтись без стабильной группы разработчиков, накапливающих специальные знания и перераба­ тывающих эти знания в углубленную модель. Ни коротких путей, ни волшебных палоч ек здесь не существует .

Э скалация дистилляции Различные приемы дистилляции, которым посвящена оставшаяся часть этой главы, можно при менять почти в любом порядке. Тем не менее они отличаются друг от друга по степени радикальности их воздействия на архитектуру модели .

Простой шаблон ВВЕДЕНИЕ В ПРЕДМЕТНУЮ ОБЛАСТЬ ( DOMAIN VISION STATEMENT) передает основные понятия и их значение при минимуме вложенных усилий. Шаблон СХЕМАТИЧЕСКОЕ ЯДРО ( HIGHLIGHTED CORE) помогает усовершенствовать коммуника­ цию между разработчиками и процесс принятия реlпений при этом не требуя практи­ чески никаких модификаций архитектуры .

При более радикаЛЫ-IОl\lI рефакторинге и изменении модульной структуры явно выде­ ляются НЕСПЕЦИАЛИЗИРОВАННЫЕ ПОДОБЛАСТИ (GENERIC SUBDOMAINS), с которыми по­ том можно работать отдельно. Имея гибкую, ИНфОРl\lIативную и разнообразную архитектуЧАсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ ру, можно легко инкапсулировать СВЯЗНЫЕ МЕХАНИЗМЫ (COHESIVE MECHANISMS). Убрав эти отвлекающие факторы, мы тем самым проясняем структуру СМЫСЛОВОГО ЯДРА .

Изменив модульную структуру ВЫДЕЛЕННОГО ЯДРА (SEGREGATED CORE), можно сде­ лать ЯДРО непосредственно видимым даже в коде, что облегчает будущую работу над мо­ дельюЯДРА .

А наиболее амбициозный замысел из всех - это АБСТРАКТНОЕ ЯДРО (ABSTH.ACT CORE), которое выражает самые фундаментальные понятия и отношения в чистом виде и требует большой работы по реорганизации и рефакторингу модели .

Каждый из перечислеНIIЫХ подходов требует соответственно больших усилий, чем предыдущий. Но чем тоньше сточить лезвие ножа, тем острее оно станет. Последова­ тельная дистилляция l\Ilодели нредмеТI-IОЙ области порождает ценный актив, который придает всему программному продукту скорость, гибкость и точность исполнения .

Для начала можно попробовать отделить наименее специализированные аспекты мо­ дели. НЕСПЕЦИАЛИЗИРОВАНIlЫЕ ПОДОБЛАСТИ (GENERIC SUBDOMAINS) представляют собой противоположность СМЫСЛОВОМУ ЯДРУ (CORE DOMAIN), и контраст между ними проясняет смысл как того, так и другого понятия.. .

Неспециализированные подобласти Некоторые части модели добавляют ей сложности, не содержа и не передавая спе­ циального знания. Все лишнее затрудняет понимание и различение СМЫСЛОВОГО ЯДРА (CORE DOMAIN). Модель загромождается общеизвестными или узкоспециализирован­ ными принципами, но не основными, а вспомогательными подробностями. Тем не ме­ нее, несмотря на их лишенный специализации характер, такие элементы являются су­ щественными для функционирования системы и полноценного выражения модели .

В вашей модели наверняка есть такая часть, которую нужно воспринимать как само собой разумеющуюся. Она, несомненно, входит в модель предметной области, но абстра­ гирует такие понятия, которые, скорее всего, встречаIОТСЯ еще во многих областях дея­ тельности. Например, организационная схема компании может понадобиться в той или иной форме в таких разных отраслях, как перевозки, банковское дело или производство .

Еще один типичный пример - это учет прихода-расхода и прочая работа с финансами, которая встречается во многих приложениях и может быть представлена одной общей моделыо бухгалтерского учета .

Часто как раз на второстепенные вопросы из предметной области уходит СЛИШКОlVl много усилий. Лично я своими глазами наблюдал в двух разных проектах, как лучшие программисты несколько недель занимались представлением даты и времени в разных часовых поясах. Такие компоненты, конечно, должны работать, но это не концептуальное ядро системы .

Но даже если настолько общий элемент модели считается критически важным, в мо­ дели предметной области, в целом, все же нужно подчеркивать наиболее производитель­ ные и специализированные аспекты системы, и структурировать ее нужно так, чтобы именно эта часть получала наиболее мощное развитие. А это трудно сделать, если СМЫСЛОВОЕ ЯДРО смешивается с разными побочными факторами .

Определите, какие из связных подобластей модели не являются основным мотивом к написанию вашего приложения. Рефакторингом выделите модели этих подобластей, имеющие общий характер, и поместите их в отдельные МОДУЛИ. Не оставляйте в них ни следа специфики вашего приложения .

Как только такие области выделены, установите для них более низкий приоритет их дальнейшей разработки, чем у СМЫСЛОВОГО ЯДРА, и постарайтесь не поручать работу

–  –  –

При разработке таких пакетов у вас может быть несколько дополнительных вариан­ тов действий .

Вариант1.fотовое реmение Иногда можно купить готовое программное решение или взять для него открытый общедоступный код .

Преuмущества Меньше кода придется разрабатывать самим .

• Вопросы сопровождения и доработки выносятся за пределы проекта .

• Код, скорее всего, написан более удачно, опробован во многих местах, а поэтому • более надежен и завершен, чем код собственного изготовления .

Недостатки Прежде чем использовать код, его все равно придется изучить и оценить .

• При нынешнем состоянии контроля качества в нашей индустрии нельзя полно­ • стью рассчитывать на правильность и надежность кода .

Код может быть перегружен лишними элементами с точки зрения ваших потреб­ • ностей; его интеграция может отнять больше времени, чем написание собственной урезанной версии .

Элементы извне обычно не так уж "гладко" интегрируются со своими собствен­ •

–  –  –

если это не так, могут возникнуть трудности с точными ссылками на объекты­ СУЩНОСТИ (ENTITIES) из других ваших пакетов .

Может проявиться зависимость от системной платформы, компилятора и Т.Д .

• Готовые решения по реализации подобластей можно рассмотреть как вариант, но обычно они не стоят затраченных усилий. Я встречал успешные приложения с очень сложными требованиями к делопроизводству, которые пользовались внешними систе­ мами делопроизводства через программные интерфейсы (API). Я видел и успешный пример пакета протоколирования ошибок, глубоко интегрированного в приложение .

Иногда НЕСПЕЦИАЛИЗИРОВАННЫЕ ПОДОБЛАСТИ (GENERIC SUBDOMAINS) оформляются в виде сред или библиотек, реализующих очень абстрактную модель, которую можно ин­ тегрировать с вашим приложением и уже там придать ей специализацию. Чем более об­ щий характер имеет вспомогательный компонент и чем более дистиллирована его собст­ венная модель, тем больше шансов получить от них пользу .

Вариант 2. Общедоступ ная архитектура или модель Преuмущества Более проработанная, чем "доморощенная"; отражает знания многих людей .

• Наличие качественной документации .

–  –  –

Может оказаться перегруженной ЛИlIпrими элементами или не совсем соответст­ • вуюп{ей KOHKpeTHIJIM потребностям .

ТОМ Лерер (Toln LeI1rer), автор комических песен 1950-60-х годов, как-то сказал, что секрет успеха в математике - это "плагиат и еще раз плагиат; пусть ничья работа не ус­ кользнет от ваших глаз... только не забудьте назвать это исследованием"l. Это хороший со­ вет по моделироваНИIО преlметных областей, особенно при работе с их НЕСПЕЦИАЛИЗИ­ ровАнныIии ПОДОБЛАСТЯМИ .

ЛУЧIlIе всего это получается, если модель широко раСIIространена - как, например, модели из книги [11 J. Подробнее см. главу 11 .

Если в отрасли уже имеется строго формализованная, установившаяся модель, вос­ пользуйтесь ею. На ум сразу приходят бухгалтерия и физика. Это не просто строгие и четко опредсленные области знания, они еще и повсеместно распространены, общеиз­ вестны, что снижает затраты на TCKYlHee и пеРСlIективное обучение сотрудников. (См. в главе 10 об использовании обlцепринятого формализма.) Не считайте себя обязанными реализовать все аспекты общедоступной модели, если можете выделить упрощенное замкнутое подмножество, которое отвечает вашим по­ требностям. Но в случае наличия хорошо обкатанной и хорошо документированной а еще лучше формализованной готовой модели нет смысла изобретать велосипед .

Ва риант з. Вынос реа лиза ции на ау тсорсинг Преu.м.ущества Освобождает ключевых сотрудников для работы над СМЫСЛОВЫМ ЯДРОМ, где • требуется и накапливается больше всего знаний по предметной области .

Позволяет вести дополнитеЛЫ--JУIО разработку, не увеличивая число собственных • сотрудников, но и "не рассеивая" знания о СМЫСЛОВОМ ЯДРЕ .

Вынуждает к интер(рейсно-ориентированному проектированию и помогает сохра­ • нить обобщенный вид подобласти, поскольку наружу передается только техниче­ ское задание .

Нед остатки Все-таки требует затрат времени со стороны основных разработчиков, потому что • интерфейс, стандарты разработки кода и другие важные аспекты необходимо со­ гласовывать .

Влечет за собой дополнительные трудозатраты при передаче кода заказчику, по­ • скольку требуется lIОНЯТЬ полученный код. (Но эти затратыI все же меньше, чем для специализированныIx подобластей, потому что модель общего характера, ско­ рее всего, не потребует для своего Ilонимания каких-то особых знаний.) Качество кода может оказаться переменчивым, хуже или лучше в зависимости от • соотношения между группами разработчиков .

При выпосе работ на аутсорсинг ваЖНУIО роль могут сыграть автоматизированные тесты. От субподрядчиков необходимо требовать модульпых тестов для кода, который они предоставляют. Самый надежный подход, который гарантирует должный уровень качества, четкое техническое задание и безупречную реинтеграЦИIО это спецификация 1 Plagiaгizel Plagiarize. Let по one's work evade your eyes.... Only Ье sure always to саП it please, research .

–  –  –

Конечно, и этот подход тоже хорошо сочетается с "общедоступной архитектурой или моделью" .

Именно в НЕСПЕЦИАЛI13ИРОВАННЫХ ОБЛАСТЯХ уместно пuпробовать применить внешние архитектурные решения, поскольку для этого не требуется глубокое знание специализированного СМЫСЛОВОГО ЯДРА, и в процессе работы такое знание не приобре­ тается. Соображения конфиденциальности не играlОТ тут особой роли, поскольку в таких модулях практически отсутствует конфиденциальная информация, технологии или ме­ тодики. Неспециализированная подобласть позволяет не нагружать ЛИIlIНИМИ знаниями тех, кого не интересует глубокое знание предметной области .

Надо полагать, что со временем наше определение того, что входит в СМЫСЛОВОЕ ЯДРО модели, будст сужаться. Все больше и болыпе неспециализированных моделей бу­ дут доступны в виде готовых сред, библиотек ИЛII, по крайней мере, об1педоступных мо­ делей либо аналитических шаблонов. Пока что болыпую часть таких моделей приходит­ ся разрабатывать самостоятельно. Однако отделять их от СМЫСЛОВОГО ЯДРА это по­ лезный задел на будущее .

Пример Повесть о дву х ча сов ых поя са х2 Дважды в разных проектах мне приходилось наблюдать, как ЛУЧIJlие программисты це­ лыми неделями занимались проблемой хранения и преобразования времени из одного ча­ сового пояса в другой. К таким работам я OTHOIUYCb с подозрением, но иногда они необхо­ димы. В этих же двух проектах можно увидеть пример практически идеального контраста .

В первом предпринималась попытка спроектировать программу для организации грузо­ перевозок. Для составления графиков движения по международным маршрутам критически важно правильно вычислять время, а поскольку все такие гра(рики отслеживаются по мест­ ному времени, скоординировать перевозки без преобра.10вания времени невозможно .

Убедительно обосновав потребность в этой функции, рзработчики ПрИСТУlIИЛИ к разработке смыIJIовогоo ЯДРА (CORE DOMAIN) и первых итераций самого приложения, иснользуя ИМСIОЩИССЯ в наличии классы для работы со временем и (риктивные данные. По мере развития приложения стало ясно, что имеЮlциеся классы не отвечают своей задаче, и

–  –  –

354 ЧАстьIV.СТРАТЕГИЧЕСКОЕПРОЕКТИРОВАНИЕ проблема очень сложна из-за вариаций по странам и неопределенности линии перемены дат (International пше Line). Требования l( функциям прояснились, И разработчики поискали готовое решение, но не нашли. Оставался сдинственный вариант - написать его самим .

Для РСlIIения задачи требовалось провести исследования и выполнить очень точное ПРОСКТИРОВ(lllие, так что руководители группы выделили для этого одного из ЛУЧllIИХ ПРОI1)аМl\НIСТUВ. Но ВЫIIолнение этой раБотыI не требовало специальных знаний в области грузоперевозок и не развивало их. Поэтому PYKOBO/ICTBO реlIIИЛО поручить ее программисту, работаВlпему 110 BPCMCI-Il IО МУ контракту .

11рограммист lle начаТJ работу с нуля. 01.1 изучил несколько СУlцеСГВУЮlЦИХ реализаций часовыlx поясов, БОЛЫПИIIСТВО 113 которыIx не удовлетворяло выlвигавIllимсяя трсбоваНИЯlVI, и РСllIИЛ адаптировать открытое оБIцеДОСТУПIIuе рСlllсние из системы BSD Unix, где имелась обпгирная база даНIIЫХ и реализация па языке с. Он восстановил програlVIМНУЮ логику и па­ IIИСaТI процедуру импортиговапия для базы дапIIыI• .

Проблема оказалась еlIе сложнее, чем можно было о)кидать (например, в осоБыIx слу­ чаях нужно было импортировать базу laHHbIx), но код был написан и интегрирован с ЯДРОМ, и финальный программнътй ПРОJLУКТ сдан в эксплуатацию .

В другом проскте все ПОllIЛО совершенно по-другому. Страховая компания разраба­ тывала новую систему обработки страховых нрстензий и планировала фиксиговать вре­ мя различных событий (время ДОРО)J(I-Iо-траНСIIОРТПОГО происшествия, бури с градом 1I т.д.) Эти данные должны были записываться но местному времени, так что требовалась (рункция преобразования вреlVlени часовых поясов .

К lVlomeI-IТУ, когда я появился в проекте, у них у;ке БыIл наэначен на эту работу молодой, но очень толковый програМlVlИСТ. Правда, еlпе НС БыIоo готово точное техническое задание на приложение и не преднринималась попьrтка написать даже перВУIО его итераЦИIО. Но нрограммист с ГОТОВIIОСТЫО взялся за априорное ностроение модели часовых поясов .

Так как было неизвестно, что конкретно потребуется, руководство решило, что l\fодель должна БыIьь достаточно гибкой и адаптироваться к чеl\1У угодно. Задача БЫЛа трудная, и програlVLlVIИСТ, которому поручили работу, нуждался в помощи, поэтому над ним был назна­ чен старший программист. Они написaТIИ сложный код, но так как его не использовaТIО ни­ какое конкретное приложение, oCTaBaТIocь неясным, правильно он работает или нет .

В силу разных причин проект "заглох", и код для работы с часовыми поясами так и не наllел l бы достаточно просто сохранять в базе данных местное вреl\1Я с меткой часового пояса и даже без преобразования, пuскольку это были базовые справочные данные, а не основа для каких-то вычислений. Даже если бы преобразование оказалось необходимым, все данные собирались только по Северной Америке, где переходы между часовыми поясами сравнительно несложны .

Главное, чем пришлось заплатить за излишнее ВНИ1Vlание к часовым поясам, - это пренебрежение смыслоI3ыlvl1 ЯДРОlV[ модели. Если бы столько же энергии вложили имснно туда, мог БыI получиться работаIОll{ИЙ IIРОТОТИП приложения и первый набросок модели предметной области. Кроме того, программистыIучастникии проекта, связанные с ним долговременIlыIии договорами, должны были бы работать в основной, страховой его части, HaKarIливая дЛЯ L'РУПНЫ Ba)lOIbIe знания .

Обе груIнIыI роднило то, что одну "вещь" они сделали правильно: четко отделили НЕСIlЕЦИАЛИЗvIРОВАНIIУЮ модель часовых поясов от СМЫСЛОВОГО ЯДРА. Если бы мо­ дель часовых поясов содержала специфику страхового дела или грузоперевозок, то глав­ ная, специализированная, модель оказалась бы слишком тесно связана со вспомогатель­ ной, неспециализиропанной, и сl\1ыIJIоI30ЕE ЯДРО стало БыI труднее для ПОlIимания (поскольку сuдержало бы ненужныe подробносги о часовых поясах). А весь МОДУЛЬ для

–  –  –

Мы, "технари", предпочитаем заниматься четко определенными проблемами, наподо­ бие преобразований времени между часовыми поясами, и запросто найдем оправдание потраченному на такие проблемы времени. Но если точно придерживаться правильных приоритетов, то предпочтительнее все-таки оказывается смыIловоЕE ЯДРО .

"Неспециализированный" не значит "хорошо переносимый" Следует отметить, что хотя рассматриваемые подобласти имеют неспециализирован­ ный характер, это еще не означает, что код для них хорошо переносим. Готовые перено­ симые решения в каких-то ситуациях YMecTHIJI, а в каких-то - нет. Но если говорить только о коде, который разрабатывается самостоятельно (в пределах основной группы или на аутсорсинге ), не следует особо заботиться о его переносимости для повторного использования. Это противоречило бы основной мотивации к дистилляции: вкладывать как можно больше усилий в СМЫСЛОВОЕ ЯДРО и лишь по необходимости - во вспомога­ тельные НЕСПЕЦИАЛИЗИРОВАНI-[ЫЕ ПОДОБЛАСТИ .

Повторное использование практикуется, но не всегда в отношении кода. Часто более выIокийй его уровень это перенос и повторное использование модели (например, оБIце­ доступной архитектуры). Если вам приходится создапать собственную модель, она мо­ жет оказаться полезной в будущем аналОГИЧНОl\lI проекте. Основная концепция такой мо­ дели может оказаться применимой по многих ситуациях, а вот саму модель не обяза­ тельно прорабатывать во всех подробностях. Бывает достаточно смоделировать и реализовать только ту часть, которая необходима для практической деятельности .

Нет необходимости всегда строить nереносшtые архитектуры, но следует строго придерживаться общей концепции. Внесение в модель специализированных элементов чревато двумя проблемами. Во-первых, это затормозит будущее развитие. Пусть сейчас вам нужна только неболыпая часть модели подобласти, но со временем потребности МОЧАстьIV. СТРАТЕГИЧЕСКОЕПРОЕКТИРОВАНИЕ гут вырасти. Внося в архитектуру что-либо, не входящее в основную концепцию, вы сильно затрудняете корректное расширение системь] без полной перестройки ее старой части и перепроектирования других модулей, которые на нее опираются .

Вторая, и более важная, причина состоит в том, что понятия/концепции, специфич­ ные для данной области деятельности, содержатся или в СМЫСЛОВОМ ЯДРЕ, или в своих собственных специализированных подобластях. Такие специализированные модели го­ раздо ценнее общих .

Управление рисками в проекте В Аgilе-методиках программирования принято управлять рисками, в первую очередь направляя усилия на самые рискованные задачи. В экстремальном программировании специально подчеркивается, как важно сразу запустить систему полного рабочего цикла .

Эта начальная система часто и оказывается технической архитектурой проекта. В связи с ней возникает искушение сначала построить периферийную систему для работы с какой­ то из I-IЕСПЕЦИАЛИЗИРОВАI-IIIЫХ вать. Будьте осторожны - это может ЛИПIИТЬ управление рисками всякого смысла .

Проекты "сталкиваются" с рисками с обеих сторон: в некоторых более рискованной является техническая сторона, а в других - моделирование предметной области. Готовая система полного цикла снижает риск только в том смысле, что она представляет "зачаточную" веРСИIО самых проблемных мест в реальной системе. Легко недооценить риск, связанный с моделированием предметной области. Оп может принять форму не­ предвиденных осложнений в мо,n:ели, нсдостаточно эффективного доступа к специали­ стам по предметной области, пробелов в ключсвых знаниях программистов .

Поэтому во всех случаях, кроме тех, когда разработчики имеют БОЛЫll0Й опыт в хо­ рошо знакомой предметной области, система первого приближения ДОЛ)l(на быть осно­ вана на какой-то части смыслового ядра, пусть даже простеЙшеЙ .

Тот же принцип относится и К Лlобой методике разработки, где на первый план выдвига­ IОТСЯ задачи с самым высоким уровнем риска. СМЫСЛОВОЕ ЯДРО относится к таким, посколь­ ку его сложность часто непредсказуема, а без него проект вообще не будет реализован .

Большинство из Iпаблонов в зтой главе демонстрирует работу над моделыо и кодом с целью дистилляции СМЫСЛОВОГО ЯДРА (CORE DOMAIN). Однако два слеДУIОЩИХ шабло­

на, ВВЕДЕIIИЕ В ПРЕДМЕТНУIО ОБЛАСТЬ (DOMAIN VISION STATEMENT) и СХЕМАТИЧЕСКОЕ

ЯДРО (HIGHLIGHTED CORE), показываIОТ, как с ПОМОIНЬЮ вспомогательной документации можно при совсем неБОЛЫllИХ затратах УЛУЧIIIИТЬ информативность и содержательность ЯДРА, а также сконцентрировать усилия разработчиков.. .

Введение в предметную область в начале проекта модели, как правило, еще нет, но потребность в придании ей нуж­ ного "направления" уже существует. На более поздних же этапах разработки бывает нужно разъяснить кому-нибудь ценность системы, не прибегая к глубокому ее изуче­ нию. Кроме того, критически важные аспекты модели предметной области могут "простираться" на несколько ОГРАНИЧЕННЫХ КОНТЕКСТОВ, но по определению эти различные модели нельзя структурировать так, чтобы выделить в них общий фокус .

Многие группы разработчиков предстаВЛЯIОТ своему руководству "концептуальное введение" (vision stateтent). l-Iаилучшие документыI такого рода рассказывают о том, что особенно ценного приложение даст организации-заказчику. В некоторых упоминается, ГЛАВА 15. Дистилляция 357 что создаваемая модель предметной области будет представлять собой стратегический актив. Обычно "концептуальное введение" перестает быть актуальным, как только про­ ект получает финансирование. Оно никогда не используется в реальном процессе разра­ ботки, а технические сотрудники его даже не читают .

ВВЕДЕНИЕ Б IIРЕДМЕТНУIО ОБЛАСТЬ (DOMAIN VISION STATEMENT) построено по об­ разцу таких документов, но фокусируется на общих характеристиках модели предметной области и ее ценности для предприятия. Оно может непосредственно использоваться как руководством, так и техническими сотрудниками на всех этапах разработки с целью пра­ пильного распределения ресурсов, принятия проектно-модельных реlпений, повышения квалификации разработчиков. Если модель IIредметной области призвана "слу)кить мно­ гим господам", этот документ может показать, как именно проект учитывает и баланси­ рует разные интересы .

Кратко опишите (примерно на страницу) СМЫСЛОВОЕ ЯДРО (CORE DOMAIN) предмет­ ной области и ее полезность - своего рода "деловое предложение". Игнорируйте те ас­ пекты, которые не отличают данную модель предметной области от других. Покажите, как модель служит разным интересам и создает баланс между ними. Напишите этот до­ кумент как можно раньше и вносите изменения по мере развития знаний о предмете .

ВВЕДЕНИЕ Б ПРЕДМЕТНУЮ ОБЛАСТЬ можно использовать как ориентир, который за­ дает группе разработчиков обlцее направление в непрерывном процессе дистилляции как модели, так и самого кода. ЭТIIМ ВВЕДЕIIИЕМ можно делиться с нетехническим персона­ лом группы, руководством и даже клиентами (конечно, в той мере, в какой там не содер­ жится конфиденциальной информации) .

Включается во ВВЕДЕНИЕ В ПРЕДМЕТНУЮ Не включается во ВВЕДЕНИЕ

В ПРЕДМЕТНУЮ ОБЛАСТЬ

ОБЛАСТЬ (хотя и важно само по себе) Система з аказ а ави а билетов Система заказа авиабwzетов Модель может представлять приоритетность Интер(рейс должен быть "подогнан" под опыт­ ных пользователей, но доступен и для начи­ пассажиров и схемы заказа билетов в авиа­ компаниях, балансируя их по гибкой методи­ нающих .

ке. Модель пассажира должна отражать Предлагается доступ через Веб, путем пере­ "взаИМООТНОIIIения", которые авиакомпания сылки данных через другие сетевые системы, хочет построить с постоянными клиентами. а также, возможно, через другие интерфейсы, Поэтому она должна представлять историю так что архитектура интерфейса будет стро­ пассажира в полезной концентрированной иться на основе XML с уровнями трансляции фОРlVlе, его участие в специальных програм­ веб-страниц и других систем данных .

мах, принадлежность к стратегическим кор­ Цветная анимированная версия эмблемы этой поративным клиентам и т.д. системы должна КСПIироваться в ЮIИСНТСКОЙ Представление разных ролей для разных системе, чтобы при следующем входе она по­ пользователей (пассажир, агент, менед­ являлась быстрее .

)КСР) позволяет расширять модель отно­ Когда заказчик резервирует билеты, нужно шениii и передавать необходимую инфор­ выполнить визуальное подтверждение заказа в мацию в систему безопасности. течение 5 секунд .

Модель должна поддерживать эффектив- Система безопасности проверяет личность ный поиск по марПlрутам и местам, а также пользователя и ограничивает доступ к тем интеграцию с другими распространенными или ИНЫlVl возможностям на основе привиле­ системами заказа авиабилетов. гий, присвоевных пользовательским ролям .

–  –  –

ВВЕДЕНИЕ В ПРЕДМЕТНУЮ ОБЛАСТЬ (DOMAIN VISION STATEMENT) дает разработчикам общее направление. Но обычно требуется еще навссти некий "мост" между достаточно общим ВВЕДЕНJ;IЕМ и полной детализацией кода или модели.. .

Схематическое ядро (OOMAIN VISION STATEl\1ENT) определяет

ВВЕДЕНИЕ ПРЕДМЕТНУЮ ОБЛАСТЬ

В СМЫСЛОВОЕ ЯДРО (CORE DOMAIN) в самых оБIНИХ выIажениях,' а опрсделения конкрет­ ных элементов ядра при этом отдаIОТСЯ на прихоть индивидуальных интерпретаций. Но если в группе не установлен ИСКJllочитеЛЫIО выIокийй уровень КО1\'fмупикабельности, то caiVlo по себе ВВЕДЕНI1Е В ПРЕДМЕТНУЮ ОБЛАСТЬ не будет иметь существенного влияния

–  –  –

Пусть члены группы в целом имеют представление о том, из чего состоит СМЫСЛОВОЕ ЯДРО (CORE DOMAIN), все равно разные люди выберут для него разные элементы, и даже один и тот же человек может изменить свое мнение за несколько дней. Умственные усилия, требующиеся для постоянного фильтрования ключевых элементов модели, "поглощают" внимание, отвлекая от проектирования, и к тому же требуют обширных знаний модели. СМЬJСЛОВОЕ ЯДРО следует сделать более простым для понимания СХЕlVIАТИЧЕСКИlVf ЯДРОlVl (HIGIILIGHTED CORE) .

Идеальный способ определения СМЫСЛОВОГО ЯДРА это существенные структур­ ные изменения в коде, но это не всегда удобно делать за короткие сроки. Фактически настолько серьезные изменения вообще нельзя предпринять, если в группе отсутству­ ет нужное видение модели .

Такие ИЗIvlенения в организации модели, как разграничение JIЕСПЕIИАЛИ3ИРОВАННЫХ IIОДОБЛАСТЕЙ (GENFHJC SUBOOl\IAINS) и некоторыс J(РУГИС, описанные в этой главе поз)ке, ГЛАВА 15. ДI1СТИЛЛЯЦI1Я 359 дают возможность почерпнуть нужную информацию из структуры МОДУЛЕЙ. Но не следу­ ет с ходу замахиваться на то, чтобы сделать этот способ выражения СМЫСЛОВОГО ЯДРА единственным .

Желательно найти какие-то более легкие вспомогательные приемы в дополнение к этим радикальным способам. В проекте могут быть какие-то ограничения, преПЯТСТВУЮIдие фи­ зическому выделению СМЫСЛОВОГО ЯДРА. Или же вы начинаете с существующего кода, в котором ЯДРО не слишком хорошо выделено, но при этом его очень нужно увидеть и поде­ литься с другими участниками для эффективного рефакторинга в направлении ЛУЧlпей дистилляции. Но и на зрелых этапах проекта несколько ТIцательно отобранных графиков или ДОКУlVlентов дают "зацепки" для ума и "опорные точки" для группы .

Такие вопросы возникают в равной степени и в таких проектах, где используются подробные UМL-модели, и в таких (например, ХР-проектах), где внеIIlней документации практически нет, а основное изложение модели содержится в коде. Группа экстремаль­ ной разработки предпочитает минимализм, ограничиваясь только временным использо­ ванием таких вспомогательных средств (например, нарисованной от руки диаграммой на стене), но TelVl не менее и они находят себе удачное применение .

Выделение особо привилегированной части модели, а также воплощаIощей ее про­ граммной реализации - это отражение модели, а не обязательно какая-то ее часть. Тут подойдет любой прием или способ, лишь бы он помог всем понять СМЫСЛОВОЕ ЯДРО .

ДЛЯ этого класса решений характерны два специальных приема .

ДИСТИЛЛЯЦИОННЫЙ документ Для описания и разъяснения СМЫСЛОВОГО ЯДРА (CORE DOMAIN) я часто пишу от­ дельный документ. Он может быть очень ПРОСТЫl\/l, - например, списком наиболее суще­ ственных концептуальных объектов. Это может быть набор графиков, концентрирую­ щихся на этих объектах и показывающих наиболее важные взаимосвязи между ними .

Документ может давать представление о самых фундаментальных взаимодействиях в модели на примерах или на абстрактном уровне .

В нем могут использоваться UML­ диаграммы классов или последовательности операI{ИЙ, нестандартные диаграммы, ха­ рактерные для предметной области, тщательно сформулированные текстовые описания, а также сочетания всего перечисленного. ДuстШUlЯЦUОННЫЙ документ - это не полный nроектный документ. Это минимально необходимое вступление, кратко очерчивающее ЯДРО и располагаlощее к более подробному исследоваНИlО тех или иных его частей. Чи­ тателю дается оБI1ая картина связи между частями и отсылки к соотвеТСТВУIОЩИМ фраг­ ментам кода за дальнейшими подробностями .

Итак, это одна из форм СХЕМАТИЧЕСКОГО ЯДРА (HIC;I-HIGHTED CORE) .

Напишите очень краткий документ (от трех до семи страниц крупным шрифтом), в котором описывается СМЫСЛОВОЕ ЯДРО (CORE ПОМАIN) и основные взаимодействия между элементами этого ЯДРА .

Здесь возникаIОТ все обычные риски, связанпы1e с наличием отдельных документов .

Документ может быть лишен сопровождения .

1 .

Документ могут не читать .

2 .

Из-за умно)кепия источников информации документ может потерять свое перво­ 3 .

начальное предназначение: упрощение сложного .

Лучший способ снизить этот риск - полный минимализм. Не вдаваясь в рутинные детали, сосредотачиваясь только на основных абстракциях и взаимодействиях между ними, можно сделать документ более устойчивым во времени, поскольку этот уровень модели оБыIноo "стареет медленнее" .

–  –  –

руководством, с которого все члены группы могут начинать знакомство с моделью и кодом .

и Разметка ядра Б первый день моей работы над проектом для большой страховой компании мне выдали экземпляр "модели предметной области" - двухсотстраничный документ, приобретенный за большие деньги у промыllленногоo консорциума. Несколько дней я пробирался через завалы диаграмм классов, которые описывали все на свете - от подробного устройства страховых полисов дО ИСКЛIОЧИТСЛЬНО абстрактных моделей отношений между людьми. Качество фак­ торинга этих моделей было различным (в некоторых даже описывались деловые регламенты, по крайней мере в сопроводительном тексте). Но с чего начать? Двести страниц.. .

Б культуре данного IIроекта очень поощрялось построение абстрактных архитектур­ ных сред, и мой преДIIlественник сосредоточился на весьма абстрактной модели взаимо­ связей людей между собой, с вещами, видами деятельности и соглашениями. Это был очень неплохой анализ таких взаимосвязей, и их эксперименты с этой моделью имели качество университетского исследовательского проекта. Но к приложению для обслужи­ вания страховой деятельности все это никак нас не приближало .

Моим первым побуждением было рубить сплеча: вернуться к небольшому смы­ (CORE DOMAIN), выполнить рсфакторинг и по ходу дела ввести остальные словому ЯДРУ сложности. Но руководство переполошилось из-за такого ОТНОIIIения. Документ был очень авторитетным. Б его разработке участвовали специалисты всей отрасли, и в любом случае они уже заплатили консорциуму значительно БОЛЫIIе, чем платили мне, IIОЭТОМУ мои реко­ мендации по радикальным изменениям не могли восприниматься ими слишком серьезно .

Но я знал, что мы должны получить совместную картину нашего ЯДРА и сосредоточить на нем усилия группы .

Бместо рефакторинга я IIрОIIIелся по документу с помощью бизнес-аналитика, кото­ рый знал много о страховом деле в целом и о требованиях к разрабатываемому приложе­ НИIО частности. Так я определил несколько разделов, содержаВlIlИХ самые существен­ в ные, оригинальные концепции и понятия, с которыми нам и нужно было работать. Я сде­ лал карту модели, которая четко показывала СМЫСЛОВОЕ ЯДРО и его взаимосвязь со вспомогательными функциями .

Разработка нового прототипа приложения началась с этой отправной точки. Было быстро создано упрощенное прило)кение, которое демонстрировало HeKoTopIJle из необ­ ходимых функций .

Килограмм макулатуры был превращен в бизнес-актив с IIОМОЩЬЮ нескольких закла­ док и желтого маркера .

Этот прием не ограничивается одними лишь объектными диаграммами на бумаге .

В группе, где пользуются UМL-диаграммами, для выделения элементов ядра можно применять "стереотипы". Если единственным хранилищем модели группа сделала про­ граммный код, то можно использовать комментарии к нему, - например, структуриро­ ванные в формате Java Doc или какую-нибудь утилиту в среде разработки. Конкрет­ ный способ не имеет значения, бы благодаря ему разработчики четко знали, что ЛИIПЬ входит, а что не входит в СМЫСЛОВОЕ ядро .

Итак, это другая форма СХЕМАТИЧЕСКОГО ЯДРА (HIGHLIGHTED CORE) .

Отметьте все элементы СМЫСЛОВОГО ЯДРА (CORE DOMAIN) в основном информаци­ онном хранилище модели, не пытаясь особо разъяснять их роли. Сделайте так, чтобы разработчики легко видели, что входит в ЯДРО, а что в Hero не входит .

ГЛАВА 15. ДИСТИЛЛЯЦИЯ Теперь СМЫСЛОВОЕ ЯДРО четко ВИДИМО всем, кто работает с моделыо, при достаточно неБОЛЬUIИХ усилиях и затратах на сопровождение по крайней мере, настолько, насколько ХОрОIПО модель q)акторизована для различения сравнительной значимости ее частей .

ДИСТИЛЛЯЦИОННЫЙ документ как методическое средство Теоретически в проекте, организованном на принципах экстремального программи­ рования, любая пара (два совместно работаЮllИХ программиста) может изменять любой код в системе. На практике некоторые изменения влекут за собой важные последствия, и поэтому трсбуют более серьезного сопровождения и координирования. IIри работе па llнфраструктурном уровне влияние изменений может быть оч евид ным, но на типичном уровне IIреД\1етной области это не так .

Имея ПОI-Iятие о СМЫСЛОВОМ ЯДРЕ DOMAIN) предметной области, такое влия­ (CORE ние можно прояснить. Изменения в СМЫСЛОВОМ ЯДРЕ должны иметь болыпое влияние на модель. Изменения в широко используемых неспецпализированных элементах могут потребовать больших модиф.икациЙ кода, но они все равно не приводят к таким концеп­ туальным сдвигам, как изменения в ЯДРЕ .

Используйте листилляционный документ как руководство к деЙСТВИIО. Когда разработ­ чики понимаIОТ, что в дистилляционный документ тоже нужно вносить изменения, чтобы синхронизировать его с кодом или моделыо, тогла они обращаIОТСЯ за консультацисЙ. Они либо фундаментально изменяют эле:менты СМЫСЛОВОГО ЯДРА, либо меНЯIОТ границы ЯДРА, а может быть, и что-нибудь еще. НеоБХОдИl\10 наладить распространение информации об ИЗl\fСНСНИИ ЯД РА между всеlVIИ членами ГРУIIПЫ по всем используемым в пей каналам связи, в том числс путеl\f раЗJ{ачи новых версий ДИСТIIЛЛЯЦИОI-IНОГО ДОКУl\fспта .

Если дистилляционный документ выделяет существенные элементы СМЫСЛОВОГО ЯДРА, то он служит практическим индикатором значимости изменений в модели. Если изменения в модели или коде влияют на дистилляционный документ, это требует со­ гласования с друrими членами rруппы. При внесении изменения необходимо немед­ ленно сообщать о нем всем участникам и распространять среди них новую версию до­ кумента. Изменения за пределами ЯДРА или в деталях, которые не включены в дистил­ ляционный документ, можно вносить без консультаций и извещений; члены rруппы ознакомятся с ними в рабочем порядке. Так разработчики получают полную автоно­ мию, декларируемую в экстремальном проrраммировании .

** *

–  –  –

Связные механизмы Инкапсуляция механизмов работы - это стаI IдарТII ы i i припцип объеКТIIо-ориентиро­ ванного программировапия. Упаковка сложных алгоритмов в методы с инq)ормативными именами отделяет "как делать" от "что делать". Такие приемы помогаlОТ лучше IIонимагь ар­ хитектуру программ и нользоваться ею. И все же здесь есть свои естествен НЬIе ограничсния .

362 ЧАСТЬ IV. СТРАТЕГИЧЕLКОЕ lIРОЕК'ТИРОВАIlИЕ Иногда вычисления настолько усложняются, что начинают "затуманивать" архи­ тектуру. Концептуальное "что" становится трудно увидеть за обилием механических "как". Большое количество методов с алгоритмами для решения задачи заслоняет со­ бой те методы, которые эту задачу ставят .

Изобилие функциональных процедур - это симптом проблем с моделью. УглуБЛЯIОЩИЙ рефакторинг может дать модель и архитектуру, элементы которых лучше приспособлены к реlпению основной задачи. Первое, что нужно искать чего добиваться, - это модель, которая и упрощает вычислительные механизмы. Но время от времени приходит понимание, что те или иные части механизма сами по себе (внутренне) концептуа7IЬНО связны. Такая концептуаль­ расчетная часть, вероятно, не ВКJпочает в себя все громоздкие вычисления, которые нам ная

–  –  –

циям хорошо документированным категориям алгоритмов. Функциональные воз­ или (INTENTION­ можности среды покажите с помощью ИНФОРМАТИВIIОГО ИНТЕРФЕЙСА REVEALING INTERFACE ). После этого другие элементы предметной области можно будет сосредоточить на выражении основной задачи ("что делать"), а тонкости ее решения ("как делать") передать новой среде .

Выделенные механизмы ставятся во вспомогательное положение и оставляют после (CORE себя небольшое, выразительное СМЫСЛОВОЕ ЯДРО DOMAIN), которое затем поль­ зуется механизмами через интерq)ейс в декларативном стиле .

Если распознать в модели известный стандартный алгоритм или формальный аппа­ рат, это позволит перенести HeKoTopYIO часть сложной архитектуры в уже изученный на­ бор понятий и концепций. Имея общий ориентир, можно реализовать нужное решение с уверенностыо и минимумом проб и ошибок. Можно рассчитывать на то, что этой ин­ формацией обладают другие разработчики или, по крайней мере, что они могут легко найти ее. Здесь есть сходство с оБIцедоступной моделью IIЕСПЕЦИАЛИЗИРОВАННОЙ ( GENERIC SUBDOMAIN), 110 задокументированный алгоритм или вычисли­ ПОДОБЛАСТvl тельный метод попадается чаще, 1I0ТОМУ что ЭТО хорошо изученный пласт науки про­ граl\tlмирования. Тем не менее достаточно часто приходится и создавать что-то новое .

В таком случае сосредоточьтесь на узком частном расчетном случае не примешивайте и

–  –  –

Пример Механизм в организационной диаграмме Мне довелось lIоучаствовать в подобном процессе, работая в проекте, где понадоби­ лась довольно сложная модель организационной диаграммы. Модель представляла тот факт, что один человек работает на другого (в определеННОl\tl подразделении организа­ ции). Она предлагала интерфейс, посредством которого можно было задавать нужные вопросы и получать ответы. Большинство этих вонросов имело примерно такой вид: "кто данной цепочке субординации имеет полномочия утверждать это?" или "кто в этом от­ в деле имеет нраво реПlать такую-то проблему?". Разработчики поняли, что глаВНУIО слож­ ность в :этой работе представляет трассировка ветвей организационного дерева в ноисках ГЛАВА 15. ДИСТИЛЛЯЦvIЯ нужных людей или взаимосвязей. Именно такие задачи решаIОТСЯ хорошо формализо­ ванным аппаратом Т.е. наборов узлов, соединенных отрезками вместе lрафов, (ребрами), с правилами и алгоритмами обхода графов .

Субподрядчик реализовал программную среду для трассировки графов в виде СВЯЗНОГО МЕХАНИЗМА (COl-fЕSIVЕ MECHANISM). В этой среде использовалась стандарт­ ная терминология графов и алгоритмы, знакомые большинству нрограммистов­ прикладников и подробно описанные в учебниках. Реализованный граф ни в коей мере не имел самого общего характера. Это было подмножество концептуального набора по­ нятий, охватываЮlцее только функции, необходимые для наIпей организационной моде­ ли. Но имея ИНФОРМАТИВНЫЙ ИНТЕРФЕЙС (INTENTION-REVEALING INTERFACE), не стоит слишком беспокоиться о средствах, которыми "добывается" нравильный ответ .

Теперь в организационной модели можно было просто декларировать, используя стандарТНУIО теРМИНОЛОГИIО графов, что каждый человек ---- это узел, а каждая взаимо­ связь между ЛIОДЬМИ - это ребро графа, соеДИНЯIощее узлы. После этого механизм среды для работы с графами предположительно был способен найти взаимосвязь между любы­ ми двумя ЛIОДЬМИ .

Если бы механизм был встроен в модель предметной области, это обернулось бы дву­ мя неприятностями. Во-первых, модель была бы привязана к конкретному методу реше­ ния задачи, что ограничивало бы варианты будущего развития. Во-вторых, что более су­ щественно, модель организации стала бы гораздо сложнее и запутаннее. Разделение ме­ ханизма и модели lIОЗВОЛИЛО описывать организации в декларативном стиле, что гораздо нагляднее. А сложный код для манипулирования графами был вынесен в чисто механи­ стичеСКУIО вспомогатеЛЬНУIО среду и основывался на проверенных алгоритмах, которые можно было сопровождать и тестировать отдельно .

–  –  –

10) .

Iпаблоне (см. главу Сложные операции по проведению сравнений и комбинирования можно полностью вынести во вспомогательную среду .

* * * Сравнение связных механизмов и неспециализированных подобластей Как НЕСПЕЦИАJIИЗИРОВАННЫЕ ПОДОБЛАСТИ (GENCRIC SlJB[)OMAINS), так и СВЯЗНЫЕ МЕХАНИЗМЫ (COHESIVE MECI-IANISMS) вводятся тогда, когда ссть необходимость разгру­ зить СМЫСЛОВОЕ ЯДРО (CORE DOMAIN). Разница состоит в принимаемых ими на себя обязанностях. НЕСПЕЦИАЛИЗИРОВАННАЯ ПОДОБЛАСТЬ основана на смысловой модели, которая представляет определенные аспекты ВЗГЛЯJLа разработчиков на обrцую проблему .

В этом она принципиально не отличается от СМЫСЛОВОГО ЯДРА, только является менее центральной, важной и узкоспециализированной. СВЯЗНЫЙ МЕХАНИЗМ же никоим об­ разом не представляет предмеТНУIО область; он решает HeKYIO чаСТНУIО вычислитеЛЬНУIО задачу, поставленную смысловыми моделями .

Итак, lVlодель говорит "надо" СВЯЗНЫЙ МЕХАНИЗМ отвечает "есть!" .

ЧАстьIV.СТРАТЕГИЧЕСКОЕПРОЕКТИРОВАНИЕ На практике, за исключением тех случаев, когда перед вами четко формализованный и общеизвестный метод расчета, это различие не столь уж очевидно - особенно на пер­ вый взгляд. В ходе последовательного рефакторинга можно либо дистиллировать более четкий механизм, либо прийти к НЕСПЕЦИАЛИЗИРОВАННОЙ ПОДОБЛАСТИ с набором ра­ нее не опознанных понятий, которые этот механизм упрощают .

Когда механизм входит в смысловое ядро МЕХАНИЗМЫ почти всегда необходимо удалять из СМЫСЛОВОГО ЯДРА модели (CORE DOMAIN). Единственное ИСКЛlочение - когда МЕХАНИЗМ сам по себе является неотъем­ лемой и КЛIочевой частыо программы, создаIощей ее KOHKypeHTHYIo ценность. Так иногда бывает с узкоспециализированными алгоритмами. Например, если бы одну из характер­ ных черт программы по управлению грузопоставками составлял особенно эффективный алгоритм для составления графиков псремещений грузов, то такой МЕХАНИЗМ можно было бы считать частыо концептуального ЯДРА. Я в свое время работал в проекте для инвестици­ онного банка, в котором их собственные специализированные алгоритмы оценки риска со­ всршенно точно принадлежали к СМЫСЛОВОМУ ЯДРУ. (На самом деле конфиденциаль­ ность этих алгоритмов охранялась столь тщательно, что даже большинство разработчиков ЯДРА не имели возможности с ними ознакомиться.) Алгоритмы, вероятно, представляли собой конкретную реализаЦИIО набора правил, действительно ПРОГНОЗИРУЮIЦИХ риск. Если провести более глубокий анализ, можно было бы построить углублеННУIО модель с явной формулировкой этих правил и инкапсуляцией вычислительного механизма .

Но это было бы уже дополнитсльное усовеРIllенствование архитектуры, слеДУIОJЦИЙ Illar в проекте. Решение о том, делать ли этот шаг, нужно было принимать итогам анализа выгоды и издержек: насколько трудно было бы разработать HOBYIO архитектуру? Насколько трудно понимать и дорабатывать текущую? Насколько упростилась бы работа при повой, усовершенствованной архитектуре для конкретного состава сотрудников? И, конечно же, имеет ли кто-нибудь представление, какой вид может принять новая модель?

Пример

–  –  –

выделение работы с графами в отдельнук) среду. Им показалось, что наличие дополни­ тельных объектов и усложнение структуры в виде выделения МЕХАНИЗМА в отдельный пакет необоснованны. Вместо этого они добавили операции над узлами графов в роди­ тельский класс организационных объсктов-СУIIЦIОСТЕЙ (ENTITIES). При этом разработ­ чики все-таки оставили декларативный рuЫiс-интерфейс организационной модели. Со­ хранилась даже инкапсуляция МЕХАНИЗМА, но уже в пределах СУIl{НОСТЕЙ организаци­ онной модели .

Часто кажется, что, совеРIIIИВ полный круг, мы приходим тому, что уже было. Но К это не совсем так. В результате обычно возникает углубленная модель, в которой более четко различаIОТСЯ факты, цели и МЕХАIIИЗМЫ. Рациональный рефакторинг сохраняет то ценное, что накоплено на промежуточных этапах работы, но при этом убирает ненуж­ ные осло)кнения .

ГЛАВА 15. ДИСТИЛЛЯЦИЯ 365 Дистилляция к декларативному стилю Декларативная архитектура и "декларативный стиль" программировапия составляли предмет главы 10, но они заслуживаlОТ особого упоминания и здесь, в главе о стратегиче­ ской дистилляции .

Смысл дистилляции состuит В том, чтобы сознательно пробиваться к сути, нс давая отвлечь себя неСУIцественными деталями. Важные части СМЫСЛОВОГО ЯДРА (CORE DоrvrЛIN ) могут следовать декларативному стилю тогда, когда вспомогатель­ ные элементы архитектуры обеспечивают поддержку экономичного языка для выраже­ ния ПUIlятиii и правил ЯДРА, в то же время инкапсулируя lVlетоды вычислений или реали­ зации правил .

СВЯЗНЫЕ МЕХАНИЗМЫ (COI-IESIVE MECHANISMS) напболее полезны тогда, когда предос­ тавляют доступ через ИНФОРМАТИВIIЫЕ с концептуально связными КОНТРОЛЬНЫМИ УТRЕР)КДЕJIияrvrи (ASSERTTONS) и ФУНК­ IП1яrvrи БЕЗ ПОБОЧНЫХ ЭФФЕКТОВ (SIDE-EFFECT-FREE FUNCTIONS ). МЕХЛНИЗМЫ и гибкая архитектура (supple design) позволяют СМЫСЛОВОМУ ЯДРУ оперировать осмыIленныыии дскларациями вместо выIоваa малопонятных сl)ункциЙ. 110 самый исключитсльныIй резуль­ тат получается тогда, когда часть смыIловогоo ЯДРА COBepluaeT качественный скачок до уровня углубленной модели и начинает сl)ункционироваТI как язык, на котором можно вы­ разить рабочис сценарии прило)кения в гибкой и краткой форме .

Углубленная модсль часто возникаст вместе с СОПУТСТВУЮIIей ей гибкой архитекту­ рой. Когда гибкая архитектура достигает эрелости, она нревращается в наглядный набор элементов, которые IVIОЖНО сочетать по однозначныIM правилам для решения с ложных за­ дач или перелачи сложной информации так же, как слuва сочстаIОТСЯ в преДJlожеппя .

На этом :этапе развития клиснтский код приобретает декларативный СТllЛЬ и BbICOKYIO степень ДИСТИЛЛЯIИИ .

Выделение НЕСПЕ1[ИАЛJ;IЗvIРОВАНIIЫХ IIОДОБЛАСТЕЙ (GI"NEH.IC SUBDOMAINS) путем рефакторинга делает код менее запутанным, а СПЯЗIIЫЕ МЕХАНИЭМЫ (COHFIVE rvlCHANIMS ) lIО;JВUЛЯlОГ IJнкапсулировать сло)кные опсрации. В резул ьтатс возникает болес сqJокусировапная модель, с меньшим количеством ПОСГОРUIIНИХ q)актороIЗ, которые не добавлятот к процессу выполнения пuльзuвательских ОlIсраций Н l lчегu llеllIlОГО. Ма­ ловероятно, что в модели нредметной области найдется удачное место для всего того, что не 0'1 НОСИТСЯ К смыI,ловомуy ЯДРУ. В Iпаблоне ВЫДЕЛЕIIНОГО ЯДРА (EGREGATED CORE) предпринимается непосредственная попытка структурно отделить crvrbIc IOnOE ЯДРО от всего остального.. .

Выделенное ядро Элементы модели могут частично работать на l,l'v11)IСЛОВО ЯДРО (СОН.Е DOMAIN), а частично играть вспомогательные роли. Элементы ядра бывают тесно связаны с не­ специализированными элементами. Концептуальная связность ЯДРА может быть не слишком сильной или плохо различимой. Смысл ЯДРА теряется, если оно слишком за­ громождено или расплывчато. Разработчики недостаточно четко видят наиболее важ­ ные взаимосвязи, отчего страдает качество архитектуры .

Выделяя ПУ1СМ рефакторинга нЕспЕцJ;lллизировАнIIыIE ПОЛОБЛЛСТ1 (CENFRIC из преДIVfетной области чаt:ТЬ заГРОlYIО)КIаI{)IЦИХ сс полроб­ UВDоrvrЛINS), мы "НЫЧlнцаСl\r" IIuстей, и :-этим дслаем сlvIыIловоЕE ЯДРО болсс четко раЗЛИЧИl\lЫl\/l. Но найти 11 разграI-ГИ­ ЧJlТЬ все эти ПОl1.0бластн дело н слсгкое, ИНОГJLа ка)кущееся бссполезным. А между ТС:\/l главное II модеЛIl остается замусоренIIыI\'1. .

СМЫСЛОВОЕ ЯДРО

366 ЧлстьIV.СТРАТЕГИЧЕСКОЕПРО[КТИРОВАНИЕ

СМЫСЛОВОГО ЯДРА

Выполните ре факторинг модели так, чтобы отделить понятия (CORE DOMAIN) от вспомогательных элементов (включая неудачно определенные) и ЯДРА, усилить связность одновременно снижая его зависимость от остального кода .

Факторизуйте все неспециализированные или вспомогательные элементы в другие объекты и поместите их в другие пакеты, даже если в ходе такого рефакторинга моде­ ли будут отделены сильно зависимые элементы .

Здесь применяются, в общем, те же llРИНЦИПЫ, что и вНЕСПЕЦИАЛИЗИРОВАННЫХ llОДОБЛАСТЯХ (GENERIC SUBDOMAINS), но с другой стороны. Связные подобласти, яв­ ЛЯIОIциеся центральными для нашего приложения, обнаруживаются и выделяются в свои собственные связные пакеты. Что делать с бесформенной массой, оставшейся по­ зади тоже важно, но не настолько. Ее можно оставить более-менее в том же виде или разделить по пакетам, выделив основныс классы. Со временем все болыпе и болыпе этой остаточной массы будет выделено рс(l)акторингом в НЕСПЕЦИАЛvJ3ИРОВАННЫЕ ПОДОБЛАСТИ, 110 в ближней перспективе полойдет ЛIобое несложное реlпение, лишь бы фокус внимания удсрживался па ВЫДЕЛЕТПIОМ ЯДРЕ (SEGREGATED CORE) .

* * * Обычно рс(ракторинг, IIорожлаIОЩИЙ ВЫЛЕЛЕПI IOE ЯДРО, состоит из слеДУЮIЦИХ этапов .

Определяется Ilодобласть СМЫСЛОВОГО ЯДРА (иногда ее мо)кно взять из ДИСТIIЛ­ 1 .

ЛЯЦИОIIIIОГО документа) .

2. ИмеIОIцие к ней ОТНОIJIение классы перемеlJ(аIОТСЯ в новый МОДУЛЬ под именем, соотвеТСТВУIощиl\tI основному IIОНЯТИЮ, которое их объединяет .

3. Выполняется рефакторинг кода, при котором "отрезаIОТСЯ" данные и q)ункцио­ нальные возможности, не выражаЮlцие это понятие непосредственно. Удаленные аспекты выносятся в классът (ВОЗl\/I0ЖНО, нопые) ДРУГИХ пакетов. Можно постарать­ ся объединить ИХ с концептуально родственными задачами, 110 не тратить СЛИIПКОМ много времени на поиск идсального реIпетrия. Основное внимание следует уделить очистке подобласти ЯЛРЛ. а также сделать ссылки из нсго на другие пакеты явными и наглядными .

4. Выполняется рефакторипг ПОВОI о lVl0ДУЛЯ ВЫДЕЛЕННОГО ЯДРА с нелыо упроще­ ния и повышения информативности взаимосвязей и взаимодействий в нем, а так­ же для минимизации и прояснения его взаимосвязей с другими модулями. (Это становится постоянной целыо рефаКТОРИIIга.)

5. выIсописанноеe повторяется с лругой ПОJобластыо ЯДРА, и так до тех пор, пока

ВЫДЕЛЕ] {НОЕ ЯДРО не будет построено .

Цена создания выделенного ядра Выдсление ЯДРА иногда делает ОТIIОIJJСНИЯ с тесно взаимосвязанными классами, не I3ХОДЯIЦИМИ в ЯДРО, менее очевидными или да.)ке более сложными. Но эта цена невелика IlO сраВНСIIИIО с такими преимуществами, как прояснение СМЫСЛОВОГО ЯДРА (CORE DOMAIN) и облегчение работы с пим .

Создание ВЫДЕЛЕННОГО ЯДРА (SEGREGATED CORE) позволяет повысить связность СМЫСЛОВОГО ЯЛРА. Есть l\IIHOfO рациональных способов разбиения модели на части .

Иногда при создании ВЫДЕЛЕННОГО ЯДРА может нарушиться целостность XOPOHIO орга­ низованного МОДУЛЯ его связность (РClктичсски приносится В жертву связности самосмыIловогоo ЯДРА. Но в итоге получаегся ЧИСlая прибыль, lак как наиБОЛЫIJая доГЛАВА 15. ДИСТИЛЛЯЦИЯ бавлепная стоимость корпоративного приложения содержится в профессиональных, специализированных аспектах модели .

За выделение ЯДРА приходится платить и такую цену, как большие трудозатраты .

Следует признать, что решение о создании выделенного ядра нагружает программистов работой по внесению изменений во все части системы .

Момент для создания ВЫДЕЛЕННОГО ЯДРА наступает тогда, когда у вас есть большой ОГРАНИЧЕННЫЙ КОНТЕКСТ (BOUNDED CONТEXT), критически важный для системы, но при этом существенная часть модели запутана большим количеством вспомогательных функций .

Эволюция коллективных решений Как и в случае многих других стратегических просктных решений, решение о перехо­ де к ВЫДЕЛЕННОМУ ЯДРУ (SEGREGATED CORE) должно приниматься всей группой разра­ ботки совместно. Для этого требуется, чтобы в группе была налажена процедура коллек­ тивного принятия решений, а также присутствовала достаточная дисциплина и скоорди­ нированность для ВОПЛОIцепия этих решений. Основная трудность состоит в том, чтобы заставить всех следовать одному и тому же определеНИIО ЯДРА, не закрепляя "намертво" само определение. СМЫСЛОВОЕ ЯДРО (CORE DOMAIN) ЭВОЛIоционирует так же, как и лю­ бой другой аспект архитектуры, ПОЭТОl\lУ опыт работы с ВЫДЕЛЕНI-fЫМ ЯДРОМ приводит к новым выводаlVl о том, что в нем составляет суть, а что является вспомогательным элс­ ментом. Эти выводы должны влиять через обратную связь на определение СМЫСЛОВОГО

ЯДРА и МОДУЛЕЙ ВЫДЕЛЕННОГО ЯДРА .

Все это означает, что новые выводы и знания следует регулярно распространять в группе, но отдельные программисты (или пары программистов) не должны действо­ вать на их основе односторонне. Какова бы ни была процедура принятия коллективных решений (достижение консенсуса или волевое реlllсние руководителя группы), она должна обладать достаточной гибкостыо ДЛЯ регулярной коррекции курса действий .

Коммуникация в группе должна быть достаточно налаженной, чтобы ВСС в группе имели одинаковое видение ЯДРА .

Пример

Выделение ядра в модели ГРУЗ0поставок Начнем с модели, показанной на рис. 15.2, как основы для координирования грузопо­ ставок .

Следует заметить, что модель сильно YIlpolILeHa по сраВНСНИIО с той, которая потребо­ валась бы для реального приложения. Но реальная модель была бы слишком громоздкой для примера. Поэтому, пусть даже при мер и недостаточно сложен, чтобы побуждать к построению ВЫДЕЛЕННОГО ЯДРА (SEGREGATED CORE), давайте 1I0ДКЛIОЧИМ воображение и будем относиться к этой модели как к слишком сложной J{ЛЯ интерпретации и воспри­ ятия в виде единого целого .

Так в чем же суть модели грузопоставок? Часто бывает полезно начать анализ с кон­ ца. Это может привести нас к вопросам ценообразования и счстов-фактур. Но в данном случае полезнее взглянуть на ВВЕДЕНИЕ В ПРЕДМЕТНУIО ОБЛАСТЬ (DOMAIN VISION

ВОТ отрывок из него:

STATEMENT) .

... Улучшить наглядность операций и предоставить средства для более бы­ строго и llадеЖ1l0го вЫnОЛllенuя требова1lИЙ клиеllтов.. .

ЧАстьIV.СТРАТЕГИЧЕСКОЕПРОЕКТИРОВАНИЕ груза сам Клиент не так важен для правильпого выполнения операций, как договор с ним .

Б другой модели требовалось сперва найти нужного Клиента согласно роли, которую тот игрсUI при доставке, а потом запросить у него нужный Договор. Эта взаимосвязь загромо­ ждала любой сценарий, который мо)кно было выстроить по модели. Новая )ке ассоциация УПрОIцает основные рабочие сценарии и придает им прямой, непосредственный характер .

Теперь мо)кно вооБIце вынести Клиента (Customer) за пределы модели .

I{стати, как обстоят дела с этим вынесением? Основное внимание уделяется выпол­ неНИIО требований Клиента, поэтому на первый взгляд он должен принадлежать к СМ ЫСЛОВОМУ ЯДРУ. Но теперь, когда Договор с клиентом (Customer Agreement) стал доступен напрямую, во взаимодействиях ме)J(ДУ объектами в ходе доставки груза собственно объект Клиент (Customer) как раз не участвует. К тому же базовая модель Клиента имеет довольно общий характер .

Есть веские доводы в пользу сохранения в ЯДРЕ объекта Участок пути (Leg). ЯДРО дол)кно носить минималистский характер, а Участок достаточно тесно связан с Графи­ ком движения транспорта (Transport Schedule), Службой маршрутизации (Routing Service) и Местоположением (Location). Однако ни один ИЗ этих объек­ топ в ЯДРЕ не ну)кеп. 110 если Участок пути стал бы фигурировать во многих сценари­ ях, которые можно построить по модели, то я бы переместил его в пакет Delivery (Доставка) и смирился бы с неудобствами его отделения от перечисленных классов .

В этом примере все определения классов остались такими же, какими были раньше .

IIo при дистилляции часто требуется рефакторинг и самих классов, чтобы разделить в них неспециализированные и снецифические для предметной области обязанности, а по­ том выполнить выделение ЯДРА .

I{aK только у нас появилось ВЫДЕЛЕННОЕ ЯДРО (SEGREGATED CORE), рефакторинг за­ вершен. Но пакет Shipping (Поставка) представляет собой остаТОЧНУIО "бесформеННУIО массу", образоваВШУIОСЯ после выделения ЯДРА. К нему можно применить новый рефакто­ ринг для более содержательной перепаковки модулей, как ноказано на рис. 15.4 .

Чтобы добиться этого результата, может понадобиться несколько рефакторингов; не обязательно делать все сразу. Здесь у пас в конце концов получился один пакет с ВЫДЕЛЕflflЫМ ЯДРОМ (SEGREGATED CORE), одна IIЕСIlЕЦИАЛИЗИРОВАННАЯ ПОДОБ­ ЛАСТЬ (GENERIC SUBDOMAIN) и два пакета, специализированных по предметной области, но во вспомогательных ролях. Углубленный анализ мог бы со временем привести к соз­ даНИIО неспециализированной подобласти для класса Клиент (Customer) или же этот класс стал бы более специализированным в области грузопоставок .

Работа по выделеНИIО полезных и информативных модулей относится к области мо­ делирования (см. главу 5). В ходе стратегической дистилляции имеет место сотрудниче­ ство между разработчиками и специалистами в предметной области, так как это часть процесс а переработки знаний (kno7f.J!edge crunching) .

–  –  –

Мы обычно работаем с большими моделями, разбивая их на более узкие подобласти, обозримые по своим размерам, и помещаем их в отдельные МОДУЛИ. Такой исключаю­ щий стиль модульной организации часто помогает сделать сложную модель более управляемой и поддающейся обработке. Но иногда создание отдельных МОДУЛЕЙ запу­ тывает или усложняет взаимосвязи между подобластями .

Если между подобластями, находящимися в отдельных МОДУЛЯХ, происходит ин­ тенсивное взаимодействие, то либо приходится создавать много ссылок между ними, что частично лишает смысла само модульное разбиение, либо организовывать косвен­ ные спосо бы взаимодействия, что ухудшает наглядность модели .

Подумайте над возможностыо установить горизонтальные, а не вертикальные грани­ цы. Полиморфизм дает нам право игнорировать детали различий между экземплярами абстрактного типа. Если большинство взаимодействий между МОДУЛЯМИ можно выра­ зить в виде полиморфных интерфейсов, то, может быть, имеет смысл выделить эти ТИIIЫ рефакторингом в отдельный МОДУЛЬ ЯДРА .

Здесь нас не интересуют чисто технические подробности. Ценным этот прием стано­ вится только тогда, когда полиморфизм интерфейсов соответствует фундаменталЫ-IЫI понятиям предметной области. В этом случае отделение абстракций позволяет снизить взаимную зависимость МОДУЛЕЙ и одновременно дистиллировать небольшое по разме­ ру, более связное СМЫСЛОВОЕ ЯДРО (CORE DOMAIN) .

Определите наиболее фундаментальные понятия в модели и выделите их рефакто­ рингом в отдельные классы, абстрактные классы или интерфейсы. Спроектируйте эту абстрактную модель так, чтобы она выражала большую част ь взаимодействий между существенными компонентами. Поместите эту абстрактную модель в собственный оставив более специализированные классы конкретных программных реали­ МОДУЛЬ, заций в их собственных МОДУЛЯХ, определяемых подобластью .

БОЛЫIIИНСТВО специализированных классов теперь будет ССЬUlаться наМОДУЛЬ АБСТРАКТ­ НОГО ЯДРА, но не на другие специализированные МОДУЛИ. АБСТРАКТНОЕ ЯДРО (ABSTRACT CORE) дает самое сжатое представление основных понятий и взаимодействий между ними .

Процесс выделения-факторизации АБСТРАКТНОГО ЯДРА не носит механического ха­ рактера. Например, если автоматически перенести в отдельный МОДУЛЬ все классы, на ГЛАВА 15. Дистилляция 373 которые часто ссылаются другие МОДУЛИ, в результате, скорее всего, получится "каlпа" .

Модслирование АБСТРАКТНОГО ЯДРА требует глубокого rrонимания ключевых понятий предмета и ролей, которые они играют в основных взаимодействиях внутри системыI .

ДРУl'ими словами, это пример углуБЛЯlощего рефакторинга, при котором обычно проис­ ходит серьезная перестройка архитектуры .

АБСТРАКТI-IОЕ ЯДРО должно в итоге стать похожим на дистилляционный документ (если бы оба применялись в одном проекте, и lI.ИСТИЛЛЯЦИОI-I НЫЙ документ развивался бы вместе с прило)кением по мере накопления знаний и углубления понимания). Разумеет­ ся, АБСТРАКТНОЕ ЯДРО выражается в виде кода, а потому имеет более строгий и завер­ шенный вид .

* ** Дистилляция в углубленных моделях Дистилляция это не только примитивное отделение тех или иных частей предмет­ ной области от СМЫСЛОВОГО ЯДРА (CORE DOMAIN). В ходе дистилляции эти подобласти совершеНСТВУIОТСЯ, особенно само СМЫСЛОВОЕ ЯДРО, посредством непрерыIногоo углуб­ ляющего рефакторинга. Происходит движение в сторону углубленной модели и гибкой архитектуры. Целыо является такая архитектура, которая бы сделала модель очевидной, и модель, выражаЮIцая предметную область в самой простой форме. Углубленная мо­ дель сама дистиллирует наиболее существенные аспектыI предметной области в простые элементы, сочетание которых дает возможность реlпать важные практические задачи, стоящие перед прило)кепием .

Хотя качественный скачок к углубленной модели приносит пользу везде, где он СМЫСЛОВОМ ЯДРЕ (CORE DOMAIN) он может коренным об­ случается, все же именно в разом изменить характер всего проекта .

Выбор целей рефакторинга Когда вам попадается плохо организованная болыпая система, с чего нужно начинать се реорганизаЦИIО? В сообществе сторонников экстремального программирования обыч­ но даIОТ один из следующих ответов на этот вопрос .

1. Начинайте откуда угодно, все равно нужен полный рефакторинг всей системы .

2. Начинайте с самого наболевшего. Рефакторинг нужен там, где именно сейчас тре­ буется реllIИТЬ конкретную задачу .

Я не могу согласиться ни с одной из этих точек зрения. Первый подход практически нс­ реализуем, за редкими ИСКJпочениями, когда в проектс работаIОТ сплошь большие профессио­ налы, причем в достаточном количестве. Во втором случае есть тенденция обходить острые углы, лечить симптомы, игнорируя причины, уклоняться от раБотыl с самыми сложными и за путанными местами. В итоге код будет все ху)ке и ху)ке поддаваться рефакторингу .

Итак, если не браться за все сразу, и не лечить только там, где болиг, чго же тогда делать?

1. В рефакторинге "по наболевшему" следует проверить, есть ли проблема в СМЫСЛО­ ВОМ ЯДРЕ (CORE DOMAIN) или в его взаимосвязях со вспомогательными.:}лемепта­ ми. Если проблсма есть, решите ее .

2. Если вы мо)кете позволить себе роскошь решать, с чего начать, начните с реорганиза­ ции СМЫСЛОВОГО ЯДРА, более четкого пыделения этого ЯДРА, очистки вспомогатель­ ных подобластей до состояния НЕСПЕЦИАЛИЗИРОВАННЫХ (GENERIC SUBDOMAINS) .

Только так можно получить максимальную отдачу от приложеНIIЫХ усилий .

–  –  –

К ак-то раз небольшую проектную qJИРМУ из Кремниевой Долины (Silicon Уаllеу) подрядили разработать симулятор для системы спутниковой связи. Работа luла нормально, разрабатывалась аРХИlектура, основанная на модели (MODEL-DRIVEN DESIGN), которая выражала и l'vIоделировала IlIИРОКИЙ спектр состояний и отказов сети .

Но веДУlцие разработчики проекта были недовольны задача была сложная. ОщуIЦая потребность ПРОЯСIlИТЬ запутанные взаимосвязи в модели, разработчики разбили наборе quilt. Дальше в главе речь пойдет О его из лоскутов 1 Дословно "лоскутное одеяло" ткани. Прuмеч. перев .

архитектуру на внутренне связные МОДУЛИ обозримого размера. И в итоге у них стало очень много МОДУЛЕЙ. В каком пакете программисту нужно искать тот или иной аспект функциональных возможностей? Куда поместить новый класс? Что конкретно имеется в виду в некоторых из этих "мелко нарезанных" пакетов? I{aK они склеиваIОТСЯ в единое целое? А приложению было еще далеко до завершения .

Разработчики хорошо взаимодействовали друг с другом, нормально ставили и peIlla­ ли повседневные задачи, но руководители проекта испытывали беспокойство от того, что проект находился на грани понятности и вразумительности. Они хотели каким-то обра­ зом организовать архитектуру так, чтобы она стала понятной и управляемой при перехо­ де на следующий уровень сложности .

Был проведен "мозговой штурм", выдвинуто много вариантов, предложены альтерна­ тивные схемы распределения по пакетам. Можно было бы сделать обзор системы в ка­ ком-нибудь документе или же использовать представления диаграммы классов в про­ грамме моделирования для перехода в нужный МОДУЛЬ. Но руководству проекта было недостаточно этих трюков .

Разработчики могли просто и наглядно рассказать о процессе работы симулятора, о прохождении данных через инфраструктуру, о поддержании их целостности и маРIПРУТИ­ зации с помощью многоуровневой системы телекоммуникационных технологий. Все дета­ ли процесса были заложены в модели, но вот общего, широкого взгляда па нее не хватало .

Недоставало некоей общей идеи, концепции из предметной области. И это были не два­ три ОТСУТСТВУIОIЦИХ в модели класса. Здесь вся модель в целом была ЛИIIlена структуры .

Разработчики посидели над решением проблемы неделю-другую, и идея начала вы­ кристаллизовываться. Нужно было наложить определенную структуру на имеющуюся систему. Весь симулятор должен был представляться в виде последовательности уров­ ней, описывающих разные аспекты телекоммуникационной системы. Нижний уровень представлял бы физическую инфраструктуру, т.е. способность передавать цифровые данные с одного узла на другой. Затем был бы уровень маршрутизации пакетов, в кото­ ром решались бы задачи перенаправления потоков данных. Другие концептуальные уровни проблемы представлялись бы другими архитектурными уровнями прило)кения .

Вся совокупность слоев отражал а бы рабочи й процесс в системе .

И разработчики приступили к рефакторингу кода в соответствии с новой структурой .

Необходимо было переопределить МОДУЛИ так, чтобы разграничить уровни. В пекото­ рыIx случаях выполнялся рефакторинг обязанностей объектов, чтобы четко вынести ка­ ждый объект на свой уровень. Соответственно, в ходе этого сами концептуальные опре­ деления уровней претерпели изменения по итогам их практического применения. Уров­ ни, МОДУЛИ и объекты развивались совместно, пока в конце концов вся архитектура не приобрела многоуровневый характер, как и было задумано .

Эти уровни не были ни МОДУЛЯМИ, ни какими-либо другими единицами кода. Они представляли собою совокупность правил более высокого уровня, опредеЛЯЮIЦИХ грани­ цы и взаимоотношения определенного МОДУЛЯ или объекта в целостной архитектуре и даже при взаимодействии с другими системами .

Введение такой упорядоченности вернуло архитектуру в состояние, удобное для по­ нимания. Теперь разработчики примерно представляли себе, где искать ту или иную фУНКЦИIО. Программисты, работавшие отдельно, могли принимать проектные решения, в целом совместимые друг с другом. Уровень сложности был поднят на новую высоту .

Даже при наличии модульного разбиения болыпая модель может оказаться слишком сложной. МОДУЛИ делят архитектуру приложения на обозримые фрагменты, но их мо­ жет оказаться слишком много. Кроме того, модульность не обязательно привносит в арЧлст ь IV. СТРАТЕГИЧЕСКОЕПРОЕКТИРОВАНИЕ хитектуру единообразие. Объект за объектом, пакет за пакетом нагромождаются хотя и необходимые, но не подчиненные единой идее проектные решения .

Строгое разграничение, создаваемое ОГРАНИЧЕI-Il-IЫМИ КОНТЕКСТАМИ (BOUNDED CONTEXTS), предотвращает путаницу, но само по себе еще не облегчает видение системы в целом .

Дистилляция полезна тем, что фокусирует внимание на СМЫСЛОВОМ ЯДРЕ (CORE DOMAIN) и отводит другим подобластям вспомогательные роли. Но все-таки остается еlце необходимость понять вспомогательные элементы и их взаимосвязи как со СМЫСЛОВЫМ ЯДРОМ, так и друг с другом. В идеале СМЫСЛОВОЕ ЯДРО должно быть на­ столько ясным и четким, чтобы не требовать дополнительных пояснений, но не всегда нам удается выйти на этот уровень .

В проекте любого размера программистам приходится работать над разными частями системы более-менее независимо. Без координации и четких правил возникает путаница из разных стилей и разных решений одних и тех )ке задач, из-за чего становится трудно понять связь между частями целого и вовсе невозможно - представить себе общую картину. Изу­ чение одной части архитектуры не "выводит" на другие ее части, и в конце концов в проекте собираIОТСЯ специалисты по разным МОДУЛЯМ, которые не способны помочь друг другу за пределами своей узкой компетенции. НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ (CONTINUOUS INTE­ GRATION) нарушается, ОГРАНИЧЕННЫЙ КОНТЕКСТ (BOUNDED CONTEXT) фрагментируется .

В большой системе, лишенной общего руководящего принципа, который позволяет воспринимать элем енты с точки зрения их ролей в структурах, распространяющихся на масштаб всей архитектуры п риложения, разработчики не видя т леса за деревьями .

Необходимо понимать роль отдельной части в целом, не углубляясь в излишние подроб­ ности этого целого .

"Крупномасштабная структура " - это своего рода язы'К, на 'Котором можно обсуж­ дать и описывать систему грубыми штрихами. Архитектурная схема для всей системы задается набором высокоуровневых концепций или правил (или того и другого вместе) .

Такой принцип организации направляет проектирование архитектуры и одновременно способствует лучшему понимаНИIО. Облегчается координирование независимых разра­ ботчиков, потому что у них теперь есть общая картина, показывающая, как роли отдель­ ных частей способствуют формироваНИIО целого .

Разработайте схему правил или ролей/взаимоотношений, распространяющуюся на всю систему и позволяющую понять место каждой части в едином целом - пусть даже без подро бного знания обязанностей всех этих частей .

Структурная схема может ограничиваться и одним КОНТЕКСТОМ, но, как правило, распространяется на несколько, обеспечивая концептуальную совместную организацию групп разработчиков и подсистем, учаСТВУЮIДИХ в проекте. Хорошая структура помогает разобраться в модели и дополняет дистилляцию .

Большинство крупномасштабных структур нельзя представить диаграммами UML, да это и не нужно. Такие структуры опредеЛЯIОТ форму модели и архитектуры, объясняют ее, но сами в ней не фигурируют. Это дополнительный уровень информации о программной архитектуре. В при мерах к этой главе вы увидите много неформальных UМL-диаграмм, на которые наложена информация о соответствующей крупномасштабной структуре .

Когда группа разработчиков невелика, а их модель не слишком сложна, для ее струк­ турной организации бывает вполне достаточно разбиения на МОДУЛИ с удобными име­ нами, lIекоторой дистилляции и неформального координирования работ в группе .

Введение крупномасштабной структуры может спасти проект, но неподходящая структура способна сильно помешать работе. В этой главе рассматриваются архитектур­ ные Iпаблоны, позволяющие успешно структурировать приложение и модель на этом уровне знания .

–  –  –

Рис. 16.1. Некоторые архитектурные шаблоны крупномасштабной структуры Эволюционная организация Многие разработчики ощутили на себе все прелести отсутствия структурированной архитектуры. Чтобы избежать анархии, в проектах часто создаются такие архитектуры, которые накладывают те или иные ограничения на процесс разработки. Некоторые тех­ нические архитектуры действительно решают частные проблемы, - например, управле­ ние сетевой коммуникацией или обеспечение сохранности данных. Но когда они прони­ кают в ту сферу, где главенствуют модели прикладпых проблем и предметной области, они могут сами создавать там беспорядок. Часто такие архитектуры мешают разработчи­ кам спроектировать модели, которые лучше всего бы подходили специфике задачи. Наи­ более навязчивые даже могут лишить разработчиков какой-то части знакомых техниче­ ских возможностей из их языка программирования. Нева)кно, технические это архитек­ туры или предметно-ориентированные, - если в пих приходится заранее принимать и фиксировать слишком много проектных решений, то в будущем они могут стать тор­ мозом развития при изменении требований заказчика и углублении понимания среди самих разработчиков .

Некоторые технические архитектуры (например, J2EE) за много лет приобрели большой авторитет, тогда как крупномасштабные структуры на уровне предметной об­ ласти остаются слабо исследованными. Потребность в них сильно меняется от одного приложения к другому .

Заблаговременное введение крупномасштабной структуры часто имеет CBOIO цену .

В ходе разработки почти наверняка найдется более подходящая для приложения струк­ тура. Может даже оказаться, что заранее предписанная структура мешает выбрать такое направление работы, которое бы прояснило И упростило программу. Какие-то возмож­ ности, конечно, удастся использовать, но потенциал теряется. Применение разных тех­ нических хитростей или попытки договориться с архитекторами только замедляют рабо­ ту. Но руководство уверено, что архитектура у)ке готова. Она была призвана упростить разработку, поэтому почему бы вам не заняться написанием кода приложения, вместо того чтобы реlпать архитектурные проблемы? Руководство и архитекторы могут л;аже 378 ЧАстьIV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ выражать готовность выслушать предложения, но если ка)кдое изменение в архитектуре сопровождается эпическими битвами, это несколько утомляет .

Хаотическое, несистематическое проектирование порождает системы, которые ни­ кто не воспринимает как единое целое и не способен сопровождать и дорабатывать .

Но и наличие заблаговременно выбранной архитектуры может стать сли шком стес­ няющим для проекта, отбирая у разработчиков и архитекторов отдельных частей про­ граммы слишком много полномочий. Вскоре разработчики начинают подгонять при­ ложение под структуру либо игнорир овать ее вообще, возвращаясь ко всем п роблемам нескоординированной разработки .

Проблема состоит, скорее, не в самом наличии обязательных к исполнеНИIО правил, а в источнике и чрезмерной жесткости этих правил. Если правила, опредеЛЯIощие архи­ тектуру, соответствуют обстоятельстваl\tl, то они не мешают, а, наоборот, помогаIОТ вести разработку в нужном направлении, а также создаIОТ единообразие .

Пусть концептуальная крупномасштабная структура эволюционирует вместе с при­ ложением, и мея возможность превратит ься в нечто совершенно отличающееся от перво­ начального. Не накладывайте СЛИIIIКом жестких и подробных ограничений на архитекту­ ру и модель; такие решения следует принимать на основе детализированных знаний .

Для отдельных частей программы могут существовать естественные или особо удач­ ные способы организации и выра)кения, неприменимые к целому. Соответственно, при введении жестких оБIДИХ правил качество этих частей падает. Выбор в пользу крупно­ маСIIIтабной структуры облегчает манипулирование моделью в целом, но структуриза­ пия отдельных частей мо)кет оказаться далеко не идеальной. Поэтому следует искать компромисс между унификацией структуры и свободой естественного выражения от­ дельных компонентов. Это противоречие можно смягчить, выбрав структуру, основан­ HYIO на реальном опыте и знании предметной области, а также избегая слишком жестких структур. Если между предметной областью и техническим заданием на программу, с одной стороны, и выбранной структурой, с другой стороны, наБЛIодается хорошее соот­ ветствие, то моделировать и проектировать архитектуру становится намного легче, по­ скольку с ходу решается много вопросов выбора .

Наличие структуры позволяет быстрее выйти на проектные решения, которые в принципе можно было бы найти, работая на уровне отдельных объектов, но с болыпими затратами времени и вразнобой. Конечно, от непрерывного рефакторинга по-прежнему никуда не деться, но он становится более управляемым и помогает разным ЛIОДЯМ при й ­ ти к согласованным решениям .

Применимость крупномасштабной структуры, как правило, шире одного ОГРАНИЧЕН­ НОГО KOI-ITEKCTA (BOUNDED CONТEXT). В реальном проекте итерационное совеРlпенствова­ ние структуры лишает ее тесной привязки к конкретной модели и развивает в ней черты, со­ отвеТСТВУЮlцие КОНЦЕПТУАЛЬНЫМ КОНТУРАМ (CONCEPTUAL CONTOURS) предметной облас­ ти. Это не значит, что структура совсем никак не зависит от модели. Но она не навязывает все­ му проекту идеи, имеющие смысл только в определенной локальной ситуации. Структура должна предоставлять полную свободу группам разработчиков в различных КОНТЕКСТАХ, чтобы те могли варьировать модель в соответствии со своими локальными потребностями .

Кроме того, крупномасштабные структуры все-таки должны накладывать полезные, практ ически ценные ограничения на процесс разработки. Например, архитекторам мо­ жет быть отказано в контроле над моделями некоторых частей системы, особенно если это внешние или старые подсистемы. В таких случаях структуру можно изменить для подстройки под те или иные внеIIIние элементы. Мо)кно задать конкретные способы взаимосвязи с внешним миром. А можно ослабить жесткость структуры настолько, что­ бы она позволяла легко обходить неудобные места .

ГЛАВА 16. КРУПНОМАСШТАБI-IАЯ СТРУКТУРА 379 В отличие от КАРТЫ КОНТЕКСТОВ (CONTEXT МАР), крупномасштабная структура­ веlЦЬ нсобязательная .

Ее следует вводить, когда это выгодно по балансу затрат и резуль­ тата и когда имеется действительно подходящая структура. В ней нет нужды в системах, которые достаточно просты для понимания после разбиения их на модули. Крупно­ масштабная структура должна вводиться в тех случаях, когда можно найти такую структуру, которая бы сделала систему намного понятнее, не накладывая неестест­ венных ограничений на развитие модели. Плохо подходящая структура хуже, чем во­ обще никакой, поэтому не надо гнаться за всеобщностью охвата, а найти минимальное решение для возникших проблем. Лучше меньше, да лучше .

Крупномасштабная структура может оказаться удобной за несколькими исключения­ ми. Эти исключения следует как-то пометить, чтобы разработчики четко знали: структуре нужно следовать всегда, не считая оговоренных случаев. Если же исключения становятся СЛИIIIКОМ многочисленными, структуру ну)кно менять или вообще отбрасывать .

* ** Как уже говорилось, построить структуру, даЮЩУIО достаточно свободы разработчи­ кам и при этом предотвращающую хаос, - немалый подвиг. По техническим архитекту­ рам для программных систем наработано очень много материала, тогда как по структу­ ризации уровня предметной области публикаций практически нет. Некоторые подходы работают против объектно-ориентированной парадигмы, - например, такие, в которых предметная область разбивается по задачам приложения либо по прецедентам (сценариям использования). Вся эта область пока плохо разработана. В разных проектах я наблюдал несколько общих образцов крупномаСПIтабных структур, четыре из которых будут рассмотрены в этой главе. Какой-то из них может подойти и вам - по крайней ме­ ре, навести на мысли относительно структуризации вашего собственного проекта .

Метафорический образ системы в индустрии разработки программного обеспечения образное, метафорическое мыш­ ление вообще IIIИРОКО распространено, особенно при работе с моделями. Но методика экстремального программирования под названием " [метафорический] образ" (metaphor) стала известна как конкретный способ использования образных представлений для упо­ рядочения разработки больших систем .

* ** Как брандмауэр 2 спасает здание от пожара, охватившего соседние постройки, так и программный "брандмауэр" или "межсетевой экран" (jirewaZl) защищает локальную сеть от опасностей, приходящих из внешних глобальных сетей. Этот образ повлиял на архитектуру компьютерных сетей и породил целую катеГОРИIО программных продуктов .

Потребителю теперь доступно множество конкурирующих систем-брандмауэров, разра­ ботанных независимо друг от друга и в значительной степени взаимозаменяемых. Но­ вички в сетевых технологиях легко YXBaTbIBaloT основную идею, и единое понимание этой концепции как среди разработчиков, так и среди пользователей не в последней сте­ пени возникло благодаря образному представлению .

И все же аналогия неполна; ее удобство оборачивается палкой о двух концах. Исполь­ зование образа брандмауэра привело к разработке программных экранов, иногда недосЭто название глухой противопожарной стены здания - нередкий пример того, как при пере­ воде на русский язык сугубо английское слово, составленное из английских же корней, приходится заменять заимствованным немецким (brandmauer, "пожарная стенка"). - Прuмеч. перев .

380 ЧАсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ таточно избирательных, подавляющих полезные потоки данных и в то же время не обес­ печивающих никакой защиты от угроз, возникающих внутри защищаемой области .

Сильно уязвимы, например, беспроводные локальные сети. Образ брандмауэра нагляден и удобен, но всякий образ имеет свою оборотную сторону3 .

Программные архитектуры часто бывают слишком абстрактными и трудными для понимания. Как разработчикам, так и пользователям нужно иметь реальный способ понять систему и совместно воспринять ее как единое целое .

Метафорические образы так глубоко пронизывают наше мышление, что находят свое отражение в любой архитектуре. Системы состоят из "уровней", расположенных "один над другим". В "центре" системы находится ее "ядро". Но иногда возникает такой образ, который становится ключом к пониманию всей архитектуры и дает разработчикам еди­ ную точку зрения на систему .

Когда случается подобное, облик системы фактически уже определяется ее метафори­ ческим образом. Разработчики теперь принимают проектные решения, согласуясь с обра­ зом системы. Самые разные части сложной системы получают единообразное истолкова­ ние на основе все того же образа. У разработчиков и специалистов по предметной области появляется точка отсчета в дискуссиях, которая может стать более реальной, чем модель .

ОБРАЗ СИСТЕМЫ (SYSTEM METAPHOR) это нестрогая, легко понятная крупномас­ ПIтабная структура, находящаяся в соответствии с объектной парадигмой. ОБРАЗ СИСТЕМЫ в конечном счете является всего лишь аналогией предметной области, и раз­ ные модели могут по-разному находиться в приблизительном соответствии с ним. Это позволяет применять ОБРАЗ в нескольких ОГРАНИЧЕННЫХ КОНТЕКСТАХ, способствуя координированию работ над ними .

ОБРАЗ СИСТЕМЫ приобрел большую популярность, поскольку это одна из ключевых методик в экстремальном программировании [5]. К сожалению, действительно полезные ОБРАЗЫ удалось найти в очень немногих проектах. Предпринимались многочисленные попытки протолкнуть этот подход в такие предметные области, где от него становилось только хуже. Чем убедительнее ОБРАЗ, тем больше риск, что архитектура воспримет та­ кие аспекты этой аналогии, которые нежелательны при решении конкретной задачи, или что "соблазнительная" аналогия попросту окажется неуместноЙ .

Учитывая все это, следует подытожить, что ОБРАЗ СИСТЕМЫ (SYSTEM METAPHOR)­ это распространенная разновидность крупномасштабной структуры, полезная для неко­ торых проектов, которая хорошо иллюстрирует само понятие структуры .

Если возникает образ (метафора) системы, захватывающий воображение разра­ ботчиков и, по всей видимости, направляющий их МЫIIIЛение в нужном направлении, примите его в качестве КРУПНОМАСШТАБНОЙ СТРУКТУРЫ. Постройте архи тектуру сис­ темы вок руг этого образа и внедрите его в ЕДИНЫЙ язык (UBIQUITOUS LANGUAGE) .

ОБРАЗ СИСТЕМЫ (SYSTEM METAPHOR) должен облегчать обсуждение системы и на­ правлять ее разработку. Это улучшает согласованность между отдельными частями

ОГРАНИЧЕННЫМИ КОНТЕКСТАМИ (BOUNDED

и даже между разли чными системы, НО поскольку никакое образное представление не может быть точным, не­ CONTEXTS) .

пр ерывно и спытывайте ОБРАЗ на соотве тствие задаче и будьте готовы отказаться от него, если он станет мешать в работе .

** * 3 Я наконец понял, что такое ОБРАЗ СИСТЕМЫ (SYSTEM METAPHOR), именно тогда, когда Уорд Каннингем (Ward Cunningham) привел нример с брандмауэром на одном из семинаров .

ГЛАВА 16. КРУПНОМАСШТАБНАЯ СТРУКТУРА 381 "Наивный образ": почему он нам не нужен Так как в большинстве проектов полезный образ построить не получается, в сообще­ стве экстремального программирования стали поговаривать о так называемом "наивном образе" (naive metaphol), под которым имеется в виду сама модель предметной области .

Этот термин некорректен уже в том отношении, что зрелая модель предметной облас­ ти очень далека от наивности. На самом деле образ типа "обработка платежной ведомо­ сти напоминает сборочный конвейер" намного более наивен, чем модель, родившаяся в результате многих итераций переработки знаний, совместной со специалистами, и про­ веренная в тесной связи с программной реализацией в рабочем приложении .

От термина "наивный образ" (naive metaphol) следует отказаться .

ОБРАЗЫ СИСТЕМЫ (SYSTEM METAPHORS) не обязательно полезны во всех проектах .

В целом, наличие крупномасштабной структуры не так уж существенно. В 12 практиках экстремального программирования роль образа системы может успешно играть ЕДИf-IЫЙ язык (UBIQUITOUS LANGUAGE). В этот ЯЗЫК следует ВКЛIОЧИТЬ ОБРАЗ СИСТЕМЫ и другие крупномасштабные структуры, если они хорошо подходят для решения задачи .

Уровни разделения обязанностей в ходе изложения мы то и дело наделяли разные объекты их собственным узким кру­ гом обязанностей. Проектирование архитектуры по разделению обязанностей примени­ мо также и в крупном масштабе .

* * * Если для каждого отдельного объекта искусственно конструируется свой круг обя­ занностей, то в такой системе нет правил, нет единообразия и нет возможности управ­ лять на уровне больших подобластей предметной области. Чтобы пр идать большой модели связность, распределению обязанностей полезно придать какую-то структуру .

Когда вы приобретаете глубокое понимание предметной области, то становятся вид­ ны крупномасштабные структуры внутри нее. В некоторых областях имеется естествен­ ная стратификация (расслоение). Определенные понятия и операции существуют на фоне других элементов, которые изменяются независимо от них, с другой скоростыо И по другим причинам. Как можно воспользоваться этой естественной структурой, сделать ее более наглядной и полезной? Стратификация предполагает деление на уровни, и это один из самых успешных архитектурных образцов-шаблонов, см. [7] и других авторов .

Уровни - это части системы, устроенные таким образом, что элементы каждой из частей знают о СУIIествовании и могут пользоваться услугами "нижних" уровней, но не зиаIОТ о СУlцествовании и независимы от уровней, лежащих "выше". При изображении взаимосвязей между МОДУЛЯМИ на схемах МОДУЛЬ, от которого зависят другие МОДУЛИ, часто располагают ниже их. Таким образом происходит естественная сорти­ ровка уровней, так что никакие объекты на нижних уровнях не зависят концептуально от верхних объектов .

Но такое хаотическое расслоение, пусть оно дюке помогает прослеживать взаимосвязи и иногда привносит в схему некий интуитивный смысл, не позволяет глубоко понять модель и руководить принятием решений. Нам необходимо нечто более систематическое .

–  –  –

Рис. 16.2. Хаотическое расслоение модели: какой смысл во всех этих nакетах?

в моделях, где присутствует естественная стратификация, концептуальные уровни мо)кно построить вокруг основных групп обязанностей, тем самым объединяя два мощ­ ных принципа: MHOroypoBHeBYIO организаЦИIО и проектирование по обязанно­ стям/ответственности (l'"esponsibility -dril)en desig;n)4 .

Эти обязанности дол)кны быть СУlцественно шире, чем те, которые обычно назнача­ ются отдельным объектам, как это будет вскоре показано. По мере проектирования но­ вых МОДУЛЕЙ и АГРЕГАТОВ выполняется их факторизация, чтобы удержать их обязанно­ сти в нределах, задаваемых общей схемой. Уже само по себе распределение обязанностей по группам с их наименованием может улучшить наглядность разбитой на модули сис­ темы, поскольку так легче интерпретировать обязанности отдельных МОДУЛЕЙ. Но соче­ тание высокоуровнеВОl о распределения обязанностей с многоуровневой структурой дает нам сразу принцип организации системы .

–  –  –

Изучите концептуальные взаимосвязи в вашей модели, а также различия в скоро­ сти и источниках изменений, происходящих в разных частях предметной области. Ес­ ли в пр едметной области обнаруживается естественное расслоение, представьте слои 4 В то время как nроекmирование по ответственности уже стало устоявшимся термином, смысл выражения все же ближе к nроектированию по обязаllНОСmя.м, т.е. на основе разделения обязанностей между программными объектами. Причина неточности - многознаЧНОС1Ь слона reponsibility. - - Прu­.меч. перев .

ГЛАВА 16. КРУПНОМАСШТАБI-fАЯ СТРУКТУРА 383 ввиде обобщенн ых абстрактн ых группы обязанностей .

Они должны нести ин форма­ цию об высокоуровневом назначении вашей сис темы и ее архитектуре. Выполните рефакто ринг модели так, чтобы обязанности каждого объекта предметной области, АГРЕГАТА и МОДУЛЯ как можно точнее совпадали с обязанностями одного слоя-уровня .

Это достаточно абстрактное определение, но оно станет понятнее после нескольких примеров. В симуляторе спутниковой связи, пример которого открывал эту главу, обя­ занности также разделялись на уровни. Успешное применение УРОВНЕЙ РАЗДЕЛЕIIИЯ ОБЯЗАI-IНОСТЕЙ (RESPONSIBILITY LAYERS) встречалось мне в самых разнообразных при­ ло)кениях: от управления производством до обслуживания финансовой деятельности .

* * * В следующем примере, рассматривая УРОВНИ РАЗДЕЛЕНИЯ ОБЯЗАНI-IОСТЕЙ, мы по­ пытаемся прочувствовать процесс выявления крупномасштабной структуры Л10БОlО ви­ да, его напраВЛЯIОIЦУЮ и ограничивающую роль в моделировании и проектировании ар­ хитектуры .

Пример Подробности: многоуровневое устройст во системы ГРУЗ0поставок Давайте посмотрим, что будет, если применить УРОВIIИ РАЗДЕЛЕНИЯ ОБЯЗАI-I НОСТЕЙ ( RESPONSIBILITY LAYERS) к приложеНИIО, обслуживающему грузопоставки и неоднократ­ но рассмотренному в примерах предыдущих глав .

К моменту нашего возвращения к этому приложению группа его разработчиков сильно продвинулась в проектировании его архитектуры но модели и дистилляции СМЫСЛОВОГО ЯДРА (CORE DOMAIN). НО по мере того, как вырисовывалась архитектура, начали появляться проблемы с объединением всех составных частей в одно целое. Сей­ час разработчики ищут такую крупномасштабную структуру, которая бы подчеркнула главную тему системы и создала для всех один общий контекст .

Вот вариант представления одной из ключевых частей модели .

–  –  –

Рис. 16.3. Элементарная моделъ из предметной области для маршрутизации грузов Разработчики "варились" в тематике грузопоставок месяцами, и в конце концов заме­ тили естественное расслоение в ее понятиях. Вполне разумно рассматривать графики движения транспорта (расписания рейсов судов и поездов), не ссылаясь на грузы, нахо­ дящиеся на борту этих транспортных средств. В то же время трудно говорить об отслеЧАсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ живании груза, не ссылаясь на транспорт, который его перевозит. Концептуальные взаи­ мосвязи тут вполне понятны. Группа легко выделила два уровня: уровень ОпераЦИЙ (Operations) и нижний по отношеНИIО к нему уровень Ресурсов (Capability) .

–  –  –

Обязанности уровня Операций На уровне ОпераЦИЙ (Operations) собрана вся деятельность компании: прошлая, нынешняя и планируемая. Наиболее очевидный объект этого уровня - объект Груз (Cargo), на котором концентрируется большая часть повседневной работы. Специфи­ Kaция маршрута (Route Specification) является органичной составной частью Груза, поскольку она задает требования к доставке. Операционный план доставки со­ держится в объекте Путь следования (Itinerary). Оба эти объекта входят в АГРЕГАТ Груз, и срок их существования привязан к временным рамкам доставки .

Обязанности уровня Ресурсов Этот уровень отражает ресурсы, которые компания привлекает для выполнения опе­ раций доставки. Классическим примером является объект Участок (Transit Leg) .

Для морских судов составляется график рейсов и предусматривается определенная гру­ зоподъемность, которая может использоваться полностью или частично .

Если бы нас интересовало управление грузовым флотом, объект Участок пути на­ ходился бы на уровне ОпераЦИЙ. Но пользователей данной системы эта проблема не волнует.

(Если бы компания занималась обеими видами деятельности и хотела их скоор­ динировать, то разработчикам следовало бы подумать о другой схеме деления на уровни:

например, "Транспортные операции" и "Операции с грузами".) Сложнее решить, куда же отнести Клиента (Customer). В некоторых областях дея­ тельности клиенты преходящи: они представляют интерес, пока посылка доставляется, а потом о них забывают до следующего раза. При таком подходе - как у службы почто­ вой доставки посылок отдельным получателям - объекты-клиенты имели бы чисто опе­ рационный характер. Но наша гипотетическая компания по доставке грузов склонна разГЛАВА 16. КРУПНОМАСШТАБНАЯ СТРУКТУРА 385 вивать долговременные отношения с клиентами, и большинство ее заказов - повторные .

При условии такого отношения к nотребителя.м данной услуги объект Клиент (Сив tomer) относится к уровню потенциальных ресурсов. Как видите, это не техниче­ ское решение. Это попытка зафиксировать и передать знание о предметной области .

Поскольку ассоциацию между Грузом (Cargo) и Клиенток (Customer) можно про­ следить только в одном направлении, ХРАНИЛИЩЕ объектов Груз должно отвечать на запрос о всех Грузах конкретного Клиента. В любом случае есть веские причины спро­ ектировать эту функцию именно так, но с применением крупномасштабной структуры это стало уже нормативным требованием .

–  –  –

..... .

*

–  –  –

\1/ *

–  –  –

По мере того как проясняются различия между операциями и ресурсами, эволюцио­ нирует и организация приложения. После нескольких недель экспериментирования раз­ работчики "нацеливаются" на другое различие. Дело в том, что большей частью оба пер­ воначальных уровня сосредоточены на ситуациях или планах как они есть. Между тем Na.ршрутизатор (Router) и многие другие элементы, исключенные из этого примера, не относятся к текущей операционной ситуации или плану действий. Эта функция помо­ гает принимать решения об изменении планов. И вот разработчики определяют новый уровень, отвечающий за Поддержху решений (Decision Support) .

386 Ч Асть IV. СТРАТЕГИЧЕСКОЕПРОЕКТИРОВАНИЕ Обязанности уровня Поддержки решений Этот уровень приложения дает пользователю в руки инструмент планирования и принятия решений, потенциально пригодный даже для автоматизации некоторых из них (например, автоматического генерирования нового маршрута для Грузов в случае, если график движения транспорта изменяется) .

это СЛУЖБА, которая помогает приемщику заказа вы­ Маршру'Z'иза'Z'ор (Router) брать наилучший маршрут пересылки Груза (Cargo). Поэтому Маршру'Z'иза'Z'ору, вне всяких сомнений, место на уровне Поддержки решеНИЙ .

Ссылки внутри этой модели четко соответствуют трехуровневой структуре, если не считать одного элемента: атрибута "предпочтительный" (is preferred) в объекте Transport Leg (Э'Z'ап перевозки). Этот атрибут присутствует, потому что компания предпочитает пользоваться своим транспортом, когда это возможно, или транспортом некоторых определенных компаний, с которыми у них заключены выгодные договоры .

Атрибут "предпочтительный" используется для того, чтобы склонить решение Маршру­ 'Z'иза'Z'ора в пользу этих видов транспорта. Он не имеет ничего общего с уровнем Ре­ сурсов (Capability); это стратегия принятия решений. Теперь, чтобы применить но­ вые УРОВНИ РАЗДЕЛЕНИЯ ОБЯЗАННОСТЕЙ, необходим рефакторинг модели .

–  –  –

Рис. 16.7. РефактОРИНl модели для обновления МНОlоуровневой структуры Такая структуризация четче выделяет Route Bias Policy (Регламен'Z' пред­ поч'Z'ения маршру'Z'а), при этом объект Этап перевозки (Transport Leg) стал в большей степени соответствовать фундаментальному понятию транспортных мощно­ стей или ресурсов. Крупномасштабная структура, основанная на глубоком понимании предметной области, часто подталкивает модель в таком направлении, которое проясня­ ет смысл ее составляющих .

Новая модель идеально вписывается в крупномасштабную многоуровневую структуру .

Разработчик, привыкший к выбранным уровням, сумеет легче выделить роли отдель­ ных частей и взаимосвязи между ними. Ценность крупномасштабной структуры возрас­ тает с увеличением сложности .

Следует отметить, что хотя этот пример проиллюстрирован модифицированной UМL-диаграммой, она здесь просто изображает расслоение на уровни. Б UML нет соот­ ветствующих обозначений, поэтому в схему добавлена дополнительная информация для удобства читателя. Если в вашем проекте основным архитектурным документом являет­ ся код, то было бы полезно иметь какое-то средство для просмотра или хотя бы перечис­ ления классов по уровням .

–  –  –

_ _

----,-

–  –  –

К ак структура вл ия ет на арх итектурное проектирование Раз уж в проекте принята определенная крупномасштабная структура, она должна учитываться при последующем принятии модельных и проектных решений. Для иллю­ страции представим себе, что нам нужно добавить новую функцию в нашу уже много­ уровневую архитектуру. Специалисты по предметной области только что сообщили, что для определенных категорий опасных материалов существуют ограничения возможных маршрутов. Те или иные материалы не разрешается провозить некоторыми средствами транспорта или через некоторые порты. Необходимо, чтобы Naршрутизатор (Router) подчинялся этим нормативным правилам .

К этой проблеме есть несколько подходов. В отсутствие крупномасштабной структу­ ры привлекательным кажется такой вариант: передать обязанность по реализации этих правил выбора маршрута тому объекту, который владеет Спецификацией маршрута ( Route Speci fication) и содержит код HazMat (Hazardous Material, "опасный мате­ риал"). Это объект Груз (Cargo) .

Беда в том, что эта архитектура не соответствует крупномасштабной структуре. Объект HazMat Pol icy Sеrviс е (Служба регламентов обращения с опасными мате ­ риалами) не составляет проблемы - он хорошо вписывается в обязанности уровня Под ­ держки решеНИЙ. Проблема заключается в зависимости Груза ("операционного" объ­ екта) от Службы регламентов обращения с опасными материалами (объекта "поддержки решений"). Если в проекте принято к исполнению деление на эти уровни, такая модель недопустима. Она сбивает с толку разработчиков, которые ожидают, что структура будет соБЛlодаться .

–  –  –

Всегда есть много вариантов построения архитектуры, и нам нужно выбрать всего один: тот, который следует правилам крупномасштабной структуры. Объект HazMat Pol i cy Sеrviс е (Служба регламентов обращения с опасными материалами) в изменениях не нуждается, но необходимо передать куда-то право использования рег­ ламентов. Давайте попробуем возложить на маршрутизатор (Router) обязанность со­ бирать соответствующие регламенты, пре)кде чем подбирать маршрут. Для этого нужно изменить интерфейс маршрутизатора так, чтобы он включал объекты, от которых мо­ гут зависеть регламенты. Далее показан вариант архитектуры для этой цели .

–  –  –

,.-_______ _ _ _ ---,

–  –  –

Рис. 16.11. Архитектура, не противоречащая многоуровневой структуре Типичные взаимодействия по казаны далее на рис. 16.12 .

Надо сказать, что эта архитектура не обязательно лучшая, чем та, другая. У обеих есть свои достоинства и недостатки. Но если все участники проекта принимают единое реше­ ние, то архитектура, в целом, будет намного проще для восприятия, а это стоит того, что­ бы кое-чем поступиться в "архитектурных частностях" .

Если же структура навязывает слишком много неуклюжих архитектурных решений, то в соответствии с принципом ЭВОЛЮЦИОННОЙ ОРГАНИЗАЦИИ (EVOLVING ORDER) ее следует пересмотреть и модифицировать, а может быть, и исключить .

–  –  –

Выбор подходящих уровней Чтоб ы найти удачные УРОВНИ РАЗДЕЛЕН ИЯ ОБЯЗАННОСТЕЙ (RESPONSIBILITY LAYERS), как и любую другую крупномасштабную структуру, надо понимать предметную область и много экспериментировать. Если в проекте допускается ЭВОЛЮЦИОННАЯ ОРГАНИЗАЦИЯ ( EVOLVING ORDER), то не так уж важно, с чего начинать, хотя неудачно выбранная исходная точка добавляет лишней работы. Структура вполне может эволю­ ционировать в нечто неузнаваемое. Поэтому предлагаемые здесь рекомендации следует применять тогда, когда вы обдумываете значительную трансформацию структуры, по размаху напоминающую создание ее заново .

В ходе жонглирования уровнями, их слияния, разбиения и переопределения следует выявлять и стараться сохранить некоторые полезные свойства структуры .

ИuформаmU61l0сmъ. Уровни должны отражать ключевые приоритетыI и реалии пред­ • метной области. Выбор крупномасштабной структуры - это в большей степени высо­ коуровневое модельное решение, а не технически-инфраструктурное. Разбиение на уровни должно подчеркивать приоритеты профессиональной сферы приложения .

Коuцеnmуалъная взаuмосвязаuuосmъ. Понятия верхних уровней должны иметь • смысл на фоне поддержки от нижних, тогда как понятия нижних уровней должны иметь самостоятельный смысл и значение .

Ншzuчuе K01-lцеnmушzъuыx коиmуров. Если объекты разных уровней меняются с • разной скоростью или по разным причинам, уровни должны отражать наличие сдвигов между ними .

ГЛАВА 1 6. КРУПНОМАСШТАБНАЯ СТРУКТУРА 39 1 Проектируя уровни для новой модели, не всегда обязательно начинать с чистого лис­ та .

Некоторые уровни могут фигурировать в целых семействах взаимосвязанных пред­ метных областей .

Так, на предприятиях, основанных на использовании крупных материальных акти­ вов (например, заводов или грузовых судов), программы по управлению материально­ техническим снабжением часто организуются в виде "Потенциального" уровня (это другое название для уровня " Ресурсов", который рассматривался в примере) и "Опера­ ционного" уровня .

Потенциал (Potential ). Что мы можем сделать? Неважно, что именно планируется • сделать. Что вообще можно сделать? Ядром потенциального уровня служат ресур­ сы организации, включая ее работников, и организация этих ресурсов. Потенциал также создается договорами с поставщиками. Этот уровень можно видеть практи­ чески в любом бизнесе, но наиболее ваЖНУIО роль он играет в таких отраслях (например, транспорте или производстве), где сама деятельность становится воз­ можной только благодаря наличию крупных материальных активов. Потенциа.п включает также и временные активы, но если деятельность основана большей ча­ стью на таких активах, то лучше выбрать для модели уровни, подчеркивающие именно это, как будет показано дальше. В примере этот уровень назывался Ре ­ сурсы (Capab i l i ty) .

Операции ( Operations). Что на самом деле происходит? Что нам удалось извлечь • из имеющегося потенциала? Как и потенциальный, этот уровень должен отражать реальное, а не желаемое, положение дел. На этом уровне мы пытаемся увидеть наши собственные усилия и виды деятельности · - что именно мы продаем, а не благодаря чему мы можем это продавать. Как правило, операционные объекты ссылаIОТСЯ на объекты потенциальные и даже состоят из них, но потенциальные объекты не должны ссылаться на операционный уровень .

Во многих существующих системах (может быть, даже в большинстве из них) из предметных областей такого рода эти два уровня полностью решают проблему, хотя воз­ можны и качественно другие, более наглядные структуры. В них отслеживается текущая ситуация и активные операционные планы, генерируются отчеты и документация. Но отслеживать не всегда бывает достаточно. Если программпый проект призван помочь пользователю, направить его, автоматизировать принятие решений, то в нем существует еще один набор обязанностей, который можно организовать в виде дополнительного уровня, лежащего выше операционного .

Поддержка реше1-lИЙ ( Decision Support). Какие действия следует предпринять, ка­ • кой установить регламент? На этом уровне выIолняетсяя анализ и принимаются решения. Анализ основывается на информации с более низких уровней - потен­ циального и операционного. Программные объекты на уровне поддержки реше­ ний могут пользоваться накопленной ранее информацией для поиска новых воз­ можностей в текущих и будущих операциях .

Системы поддержки решений концептуально зависят от других уровней (операци­ онного и потенциального), потому что решения принимаются не в вакууме. Во многих про­ ектах уровень поддержки решений реализуется с примепением технологии хранилищ дан­ ных (data warehouses). Тогда этот уровень становится отчетливо отдельным ОГРАI-IИЧЕН­ I-IbIМ КОНТЕКСТОМ (BOONDED CONTEXT) и находится с "операционными" приложениями в отношениях 3АКА3ЧИК-ПОСТАВIДИК (CUSTOMER/SUPPLIER). В других проектах он глубже интегрирован с другими уровнями, как показано в предыдущем развернутом примере. ОдЧАсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ но из естественных преимуществ многоуровневой структуры заключается в том, ЧТО ниж­ ние уровни могут существовать без верхних. Это помогает при постепенном введении но­ вых функций или наращивании высокоуровневых расширений на основу из старых опера­ ционных систем .

Еще один случай - приложения, реализующие сложные деловые регламенты (business mles) или юридические требования. Они тоже могут образовывать один из УРОВНЕЙ

РАЗДЕЛЕНИЯ ОТВЕТСТВЕНI-IОСТИ (RESPONSIBILIТY LAYER) .

Регламент ( РоНсу). Каковы установленные правила и цели? Правила и цели в ос­ •

–  –  –

Рис. 16.13. Концеnтумьные взаимосвязи и точки относитеЛЬНОlО сдвИlа уровней в системе ав ­ томатизации nроuзводства Многие предприятия не опираются в своей деятельности на заводские мощности и оборудование. Например, в сфере финансовых консалтинговых услуг или в страхова­ нии потенциал во многом определяется именно текущими операциями. Способность страховой компании принять на себя новый риск путем подписания нового страхового соглашения зависит от диверсификации ее текущей деятельности. Здесь потенциалы-IыIй

–  –  –

характеру похож на регламентный в том, что он задает цели для будущих опера­ ций, но и на операционный тоже, поскольку обязательства возникают и изменя­ ются в ходе текущей деятельности .

–  –  –

Рис. 16.14. концеnтумыlеe взаимосвязи и точки относительного сдвига уровней в системе 06служиваllИЯ ИllвестИЦИОll1l0го 6а1lка Потенциальный уровень и уровень обязательств не являются взаимоисключающими .

Если в предметной области заметную роль играют оба уровня - как, например, в транс­ портной компании с большим разнообразием услуг по доставке - то и в приложении бу­ дет присутствовать и тот, и другой. Могут понадобиться и другие уровни, специфичные для таких областей. Варьируйте, экспериментируйте, но стремитесь сделать систему уровней как можно проще. Если уровней больше четырех-пяти, работать становится не­ удобно: слишком трудно передать сущность операций, устройство предметной области, и все проблемы сложности, которые призвано было решить введение многоуровневой структуры, возвращаются в другом виде. Крупномасштабную структуру нужно постоян­ но дистиллировать .

Перечисленные пять уровней применимы в целом ряде систем управления предпри­ ятиями. Но не во всех предметных областях они способны моделировать ключевые обя­ занности объектов. В некоторых случаях принудительное приведение архитектуры к этому образцу может сделать только хуже. Но и тогда еще может существовать естест­ венный набор УРОВНЕЙ РАЗДЕЛЕНИЯ ОБЯЗАНI-I ОСТЕЙ, соответствующий задаче. Если же предметная область совсем далека от тех, которые мы рассмотрели, то, возможно, при­ дется выбрать совершенно другие уровни. В общем, следуйте своей интуиции, выберите стартовую точку и дайте архитектуре эволюционировать .

–  –  –

вести себя другая группа объектов. [Martin Fowler, "Accoиntability ", www. ma rt i n fowl e r. com] YPOBEI-Ib ЗI-IАI-IИЙ (KNOWLEDGE LEVEL) решает следующую задачу. Предположим, нам нужно, чтобы некоторая часть модели была "податливой" в руках пользователя, но при этом подчинялась более-менее широкому набору правил. Такие свойства соответст­ вуют техническому заданию на программу с конфигурируемым поведением, в которой роли и взаимоотношения между СУЩI-IОСТЯМИ (ENTITIES) должны изменяться при уста­ новке или даже в ходе работы .

Этот шаблон возникает при рассмотрении подотчетности и ответственности внутри организаций, а затем применяется к правилам проводки в бухгалтерском учете [ 1 1 ]. Хотя шаблон фигурирует в нескольких главах, там нет отдельной главы, специально посвященной ему, потому что он отличается от большинства шаблонов в книге. Вместо моделирования предметной области, а именно это компетенция других аналитических шаблонов, УРОВЕНЬ ЗНАНИЙ структурирует модель .

Чтобы поставить задачу конкретнее, рассмотрим модели "подотчетности". Организации состоят из людей и из меньших организаций; в них определяются исполняемые роли и взаимоотношения. Правила (регламенты), задающие эти роли и отношения, очень отличаются в разных организациях. В одной фирме "отделение" может возглавляться "директором", подотчетным "вице-президенту". В другой фирме "модуль" возглавляется "менеджером", который подотчетен "старшему менеджеру". Есть еще и "матричные" орга­ низации, в которых каждый сотрудник по разным видам работ подотчетен разным лицам .

В типичном приложении обычно принимается ряд предположений. Если они неадек­ ватны задаче, пользователи станут использовать поля ввода данных не для того, для чего требуется. Операции приложения будут " б ить" мимо, поскольку их семантику изменили пользователи. Тогда пользователи придумают обходные пути, чтоб ы не оказаться отре­ занными от высокоуровневых функций приложения. Им придется научиться сложным переходам от того, что они делают в своей работе, к тому, как работает само приложение .

Такое приложение - плохой помощник .

Когда систему нужно будет изменять или заменять, разработчики обнаружат (рано или поздно), что смысл ее функций совсем не таков, как они думали. Эти функции могут восприниматься совсем по-разному в разных сообществах пользователей или в разных ситуациях. Изменить что-либо, не нарушая сложившихся неформальных практик поль­ зования такой программой, будет очень сложно. Перенос данных в более продуманную систему потребует глубокого понимания сути и грамотного программирования всех этих уловок и "приемчиков" .

–  –  –

В едомость зар пл аты и пенсионных отч ислений, ч асть I Отдел кадров небольшой компании работает с простой программой для расчета ведо­ мостей заработной платы и пенеионных отчислений .

–  –  –

Рис. 16.16. Представление некоторьа сотрудников с помощью старой модели и вот руководство решает, что офисные администраторы должны перейти на пенси­ онный план с фиксированным размером пособия (defined benefit). Но проблема в том, что офисным администраторам платят почасово, а данная модель не допускает смешан­ ных вариантов. Поэтому нужно менять саму модель .

Следующее предложение очень просто: убрать все связи-ограничения .

–  –  –

Такая модель позволяет любому сотруднику выбрать любой вариант пенсионного плана. Каждому офисному администратору теперь доступна смена плана. Эту модель руководство отвергает, потому что она не отражает политику фирмы. Некоторые адми­ нистраторы перейдут на другой план, а некоторые - нет. План может сменить даже уБОРlцица. Руководство хочет иметь модель, которая реализует следующий регламент .

Офисные администраторы это сотрудники с почасовой оплатой и фиксиpoвaHHыM размером nенсии (rzлаи {'defined benefit") .

Это правило предполагает, что поле "должность" ( j ob t i t l e ) должно представлять важное понятие предметной области. Программисты могут выполнить рефакторинг и вынести это понятие в явные под названием Ешр l0уее Туре, т.е. Тип сотрудника .

Требования MO)l(HO выразить на ЕДИНОМ ЯЗЫКЕ следующим образом .

(Етрl0уее 7}'ре) ставится в соответствие один из Пен­ ТИпу СО!Z'pуднижа (Retirement Рlаn) Wlи одна из ведомостей оплаты труда .

СИОЮШХ планов На СОУДНИl(ОВ (Етрl 0уеев) налож'ена связъ -ограuиче1lие в виде Типа СОУДНИl(а (Етрl 0уее Туре) .

–  –  –

Рис. 16.20. Каждому Типу СО!l'pУДlfижа назначается nенсионный план Доступ к объекту Тип сотрудника (Ешрl0уее Туре) для его редактирования бу­ дет предоставлен только "суперпользователю", который будет вносить изменения только при изменении политики компании. Обыкновенный пользователь в отделе кадров смо­ жет изменять объекты Сотрудник (Employee) или ассоциировать их с другими Типами (Employee Туре) .

Эта модель удовлетворяет заданным требованиям. Разработчики предполагают, что здесь еще есть одно-два неявных понятия, но на данный момент это не более чем мелкие придирки. Никаких значительных идей для реализации нет, так что они сходятся на этом .

Статическая модель порождает проблемы. Но не менее серьезные проблемы могут возникнуть и во вполне гибкой системе, которая способна выразить любое возможное отношение между объектами. Такой системой было бы неудобно пользоваться, и через нее нельзя было бы реализовать правила, установленные организацией .

Писать полностью настраиваемые приложения, пригодные для любой организации, не слишком практично. Даже если каждая организация готова была бы платить за "подгонку" приложения под ее нужды, все равно организационная структура имеет тен­ денцию изменяться .

Итак, подобная программа должна предлагать пользователю возможность ее конфи­ гурирования для отражения текущей организационной структуры. Но беда в том, что до­ бавление таких возможностей в объекты модели делает их громоздкими. Чем больше гибкости, тем сложнее система .

В п р иложении, где роли и взаимоотношения между СУЩНОСТЯМИ ( ENTITIES) ме­ няются в разных си туациях, сложность может нарастать лавинообразно. Ни самые общие, ни гибко настр аиваемые модели MOryT не отве чать потребно стям пользователя .

В объектах появляются ссылки на другие типы, отр ажающие все многообразие случа­ ев, или же атр ибуты, которые используются по -р азному в разных ситуациях. MorYT р азмно жи ться классы, содержащие одни и те же данные и операции - только для Toro, чтобы реализова ть разные правила сбор ки .

ЧАсть IV. СТРАТЕГИЧЕСКОЕ П РОЕКТИРОВАНИЕ В нашу модель встраивается другая модель, описывающая ее. Самоопределение мо­ цели выносится в отдельный УРОВЕНЬ ЗI-I АНИЙ (KNOWLEDGE LEVEL), отчего все связи­ ограничения становятся явными .

УРОВЕНЬ ЗНАНИЙ представляет собою применение к уровню предметной области шаб­.IOHa REFLECTION ( ОТРАЖЕI-I ИЕ), который используется во многих программных архитек­ lурах и технических инфраструктурах. Он хорошо описан в книге [7]. Чтобы учесть ме­ няющиеся потребности, ОТРАЖЕНИЕ придает программе элементы "самосознания" и от­ :RpbIBaeT как некоторые аспекты ее структуры, так и функции для адаптации и изменения .

Это достигается разбиением приложения на "базовый уровень" (base level), в котором со­ держатся собственно его операционные обязанности, и "мета-уровень" (meta level), пред­ с-rавляющий знания о строении и поведении программы .

Показательно, что в названии этого шаблона слово "уровень" отсутствует. Хотя сход­ ство с многоуровневой структурой тут есть, для ОТРАЖЕI-IИЯ характерны двунаправлен­ ные взаимосвязи .

В языке Java имеется встроенная минимальная реализация ОТРАЖЕНИЯ в виде про­ токолов для опроса классов об их методах. Такие механизмы дают программе возмож­ ность задавать вопросы о своей собственной структуре. В CORBA есть несколько более расширенные, но аналогичные протоколы ОТРАЖЕНИЙ. В некоторых технологиях для поддержания непрерывности существования данных (persistence technologies) возможно­ сти самоописания расширены - с целью поддержки полуавтоматического отображения данных между таблицами баз данных и объектами. Есть и другие технические примеры .

Этот шаблон может также применяться на уровне предметной области .

–  –  –

Уровень знаний (knowledge level) Мета-уровень (meta level) Операционный уровень (operations level) Базовый уровень (base level) Сделаем разъяснение. Средства языка программирования, имеющие то же название reflection (оmраж'еlluе), не должны использоваться при реализации УРОВНЯ ЗНАI-I ИЙ в модели предметной области. Эти мета-объекты описывают структуру и функции самих языковых конструкций. А вот УРОВЕНЬ ЗI-IАНИЙ должен строиться из обыкновенных объектов .

YPOBEI-I b ЗНАНИЙ имеет две полезные особенности. Во-первых, он сосредоточен на предметной области приложения, в отличие от хорошо известных примеров использова­ ния ОТРАЖЕНИЙ. Во-вторых, он не претендует на максимальную общность. Как СПЕЦИФИКАЦИЯ (SPECIFICATION) может быть полезнее, чем общий предикат, так и узко­ специализированный набор ограничений, наложенный на совокупность объектов и взаимосвязей между ними, может оказаться ценнее, чем обобщенная архитектурная сре­ да. УРОВЕНЬ ЗНАНИЙ устроен проще и может передавать конкретные намерения проек­ тировщика .

Создайте отдельный набор объектов, которые MoryT использоваться для описания трук ту ры и функций базовой модели, а также накладыва ния на нее связей­ с оrра ничениЙ. Отделите эти части друr от друrа как два " уровня " : один - предельно 5 Это сокращение от названия книги et [Buschrnann Pattem- Oriented Software Architecture al., 1996] .

ГЛАВА 16. КРУПНОМАСШТАБНАЯ СТРУКТУРА

конкретный, а друrой - отражающий правила и знания, изменяемые пользователе м или " суперпользователем " .

Как и любая мощная идея, шаблоны ОТРАЖЕНИЕ (REFLECTION) и УРОВЕНЬ ЗНАНИЙ (KNOWLEDGE LEVEL) могут оказаться слишком соблазнительным. А использовать такои шаблон нужно с осторожностью. Он может снизить сложность кода, освободив объекты от необходимости быть "мастерами на все руки", но вводимая им же косвенность взаимосвя­ зей частично возвраlцает в программу эту сложность. Если УРОВЕНЬ ЗНАНИЙ усложняется, поведение системы становится трудным для понимания как разработчиками, так и пользо­ вателями. Пользователям (или "суперпользователю"), конфигурирующим программу, в конце концов понадобятся навыки программистов - да еще и мета-программистов. Если же они сделают ошибки, программа будет функционировать неправильно .

В дополнение к этому не полностью исчезает проблема пере носа данных. Когда изме­ няется структура УРОВI-IЯ ЗНАI-I ИЙ, надо что-то делать с объектами операционного уров­ ня. Бывает, что старые и новые объекты могут сосуществовать, но в любом случае тут по­ требуется тщательный анализ .

Все эти проблемы ложатся тяжким бременем на плечи проектировщика УРОВНЯ ЗНАНИЙ. Проектируемая архитектура должна быть достаточно устойчивой, чтобы реали­ зовать не только все сценарии, сформулированные в ходе разработки, но и любые, под которые пользователь может сконфигурировать приложение в будущем. Если приме­ нять YPOBEI--lb Зl IАl-IИЙ с разумной умеренностью, до той точки, в которой возможность конфигурирования оказывается критической и без этого уровня грозит исказить архи­ тектуру, то можно решать проблемы, которые другим способом одолеть очень трудно .

Пример

В едомость зарпл аты и пенсионных отч ислений, ч асть 11: уровень знаний Итак, наши разработчики снова в строю. Один из них, отдохнувший и выспавшийся, начинает "подбираться" к одному из "неуклюжих" мест в программе. Почему некоторые объекты защищены, тогда как другие могут свободно подвергаться изменениям? Сово­ купность защищенных объектов напомнила ему о IIIаблоне УРОВЕНЬ ЗНАНИЙ (KNOW­ LEDGE LEVEL), и он решил опробовать его как способ восприятия модели. И обнаружил, что существующую модель уже можно воспринимать таким образом .

–  –  –

Рис. 16.21. Выделеnие УРОВНЯ ЗНАНИЙ, nрисутствовавшего в текущей модели nеявnо 400 Члсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Ограничения на модификацию оказались на уровне знаний, тогда как обычные, повсе­ дневно используемые средства редактирования - на операционном уровне. Это удача. Все объекты над чертой описывают типы или долговременные стратегии. Тип Employee Туре (ТИп сотрудника) сразу же накладывает на тип Employee (Сотрудник) четко опреде­ ленные функции .

Разработчик как раз делился своей находкой с коллегами, когда одного из остальных программистов посетило еще одно озарение. Четкая организация модели посредством УРОВНЯ ЗНАНИЙ позволила ему понять, что именно беспокоило его в последнее время .

Б одном и том же объекте объединились два различных понятия. Он услышал это в вы­ ражении, сказанном на день раньше, но тогда не придал этому значения .

(Етрl0уее Туре) ставится в соответствие один из Типу СО'J!Pуднижа планов (Retirement Рlаn) UJlИ одна из ведомостей Пенеионных оплаты труда .

Но это же не утверждение на ЕДИНОМ ЯЗЫКЕ модели. В модели нет никакой "ведомости". Фраза сказана на языке желательном, но не фактическом. Понятие ведомо­ сти выплаты зарплаты неявно присутствовало в модели, склеиваясь с Типом сотруд­ ника (Employee Туре). До выделения УРОВНЯ ЗНАНИЙ это не было настолько очевид­ но, и сами элементы из этой ключевой фразы фигурировали все на одном и том же уров­ не... за исключением одного .

На основе этих выводов снова был выполнен рефакторинг модели, поддерживающей данное утверждение .

Необходимость в контроле пользователей над правилами ассоциирования объектов привела разработчиков к модели, содержавшей неявный УРОВЕНЬ ЗНАНИЙ .

–  –  –

Рис. 16.22. Теперь Payroll (Ведонос!l'Ъ) фиlурирует явно, отдельно от Етрl0уее Туре(Типа соуДнижа) На присутствие УРОВНЯ ЗНАНИЙ намекали специфические ограничения доступа и взаимосвязи типа "предмет-предмет". Его формальное введение в модель прояснило си­ туацию, и были сделаны новые выводы, в результате которых, благодаря выделению Ве­ ДОМОСТИ (Payroll), обособились два важных понятия предметной области .

УРОВЕНЬ ЗНАНИЙ (KNOWLEDGE LEVEL), как и другие крупномасштабные структуры, строго говоря, не является обязательным для применения. Объекты будут работать и без него, и даже в таком случае можно будет сделать и использовать выводы, приведшие к

ГЛАВА 16. КРУПНО М АСШТАБНАЯ СТРУКТУРА

отделению ВЕДОМОСТИ (PAYROLL) от Типа сотрудника (EПLрl0уее Туре). Может придти время, когда эта структура уже не будет оправдывать себя, и от нее можно будет отказаться. Но пока она, по-видимому, передает важное знание о системе и помогает раз­ работчикам "бороться" с моделью .

–  –  –

*** На первый взгляд УРОВЕНЬ ЗНАНИЙ (KNOWLEDGE LEVEL) похож на частный случай одного из УРОВНЕЙ РАЗДЕЛЕНИЯ ОБЯЗАННОСТЕЙ (RESPONSIBILITY LAYERS), особенно "регламентного" (policy). Но это не так. Бо-первых, между УРОВНЕМ ЗНАНИЙ и осталь­ ными уровнями устанавливаются двусторонние связи, тогда как среди УРОВНЕЙ РАЗДЕЛЕНИЯ ОБЯЗАННОСТЕЙ нижние уровни независимы от верхних6 .

На самом деле УРОВЕНЬ ЗНАНИЙ может сосуществовать с большинством остальных крупномасштабных структур, добавляя к ним дополнительный аспект организации .

Среда подключаемых компонентов в очень "зрелой" модели, углубленной и хорошо дистиллированной, возникает много разных возможностей. СРЕДА ПОДКЛЮЧАЕМЫХ КОМПОНЕНТОВ (PLUGGABLE COMPONENT FRAMEWORK) обычно становится актуальной уже после того, как в одной и той же пред­ метной области реализуется несколько приложений .

*** Когда реализуется совместная работа целого ряда разных приложений, основан­ ных на одних и тех же абстракциях, но спроектированных отдельно, их интеграцию ограничивает необходимость трансляции между несколькими ОГРАНИЧЕННЫМИ КОНТЕКСТАМИ (BOUNDED CONTEXTS). ОБЩЕЕ ЯДРО (SHARED KERNEL) не годится для групп, связаных недостаточно тесным сотрудничеством. Дублирование и фрагмента­ ция работ поднимает стоимость разработки и установки приложений, а их совместная работа затрудняется .

6 Автор употребляет в отношении УРОВНЯ ЗНАНИЙ слово level (собственно "уровень"), тогда как в отношении уровней разделения обязанностей - слово layer (фактически "слой"). Это разли­ чие не так уж велико и важно, но оно присутствует. Примеч. перев .

402 ЧАстьIV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ В некоторых успешных проектах архитектура разбивается на компоненты, каждый из ко­ торых отвечает за определенную категорию рабочих функций. Обычно все эти компоненты подключаются к центральному распределительному модулю, или "концентратору" (hub), ко­ торый поддерживает все нужные протоколы и умеет общаться через все предоставляемые ин­ терфейсы. Существуют и другие формы подключения компонентов. Структуру этих интер­ фейсов и распределительного модуля необходимо скоординировать между собой, а внешние части программного комплекса можно проектировать относительно независимо .

Этот шаблон поддерживается в нескольких широко используемых технических сре­ дах разработки, но не это главное. Техническая среда нужна только тогда, когда она ре­ шает какую-то существенную техничеСКУIО проблему - например, распределение или совместное использование компонента разными приложениями. А шаблон предлагает, собственно, концептуальную организацию распределения обязанностей, и применить его можно в пределах одной программы Ha Java .

Дистиллируйте АБСТРАКТНОЕ ЯДРО (ABSTRACT CORE) интерфейсов и взаимосвязей и постройте среду или библиотеку, в которой различные реализации этих интерфейсов были бы легко заменяемы. Аналогично, предоставьте любому из приложений возмож­ ность использования этих компонентов, но с условием обращения к ним строго через интерфейсы АБСТРАКТНОГО ЯДРА .

Высокоуровневые абстракции определяются и распределяются по всей системе, а специализация достигается в модулях. Центральным распределительным модулем сис­ темы является АБСТРАКТНОЕ ЯДРО (ABSTRACT CORE) внутри ОБЩЕГО ЯДРА (SHARED KERNEL). НО за интерфейсами инкапсулированных компонентов может стоять множест­ во разных ОГРАНИЧЕННЫХ КОНТЕКСТОВ (BOUNDED CONTEXTS). Такая структура по­ строена специально для тех случаев, когда разные компоненты поступают из разных ис­ точников или же инкапсулируют ранее написанные программы с целью их интеграции .

Вообще-то, компоненты вовсе не обязаны иметь в своей основе разные модели. Не­ сколько компонентов вполне может быть разработано в одном КОНТЕКСТЕ, если разработ­ чики практикуют НЕПРЕРЫВНУЮ ИНТЕГРАЦИЮ (CONTINUOUS INTEGRATION) или могут оп­ ределить другое ОБЩЕЕ ЯДРО (SHARED KERNEL) для набора "близкородственных", тесно связанных компонентов. Все эти подходы легко могут сосуществовать в крупномасштабной структуре ПОДКЛЮЧАЕМЫХ КОМПОНЕНТОВ (PLUGGABLE COMPONENTS). Еще один вариант, применимый в некоторых случаях, - это использование общедоступного языка (PUB­ LISHED LANGUAGE) для интерфейса, к которому подключаются компоненты .

у СРЕДЫ ПОДКЛЮЧАЕМЫХ КОМПОНЕНТОВ есть и свои недостатки. Один из них - чрез­ вычайная сложность этого шаблона в применении. Он требует высокой точности при про­ ектировании интерфейсов и достаточно глубокой модели, содержащей все необходимые функции в АБСТРАКТНОМ ЯДРЕ (ABSTRACT CORE). Еще один существенный недостаток­ ограниченная изменчивость приложения, недостаток вариантов развития. Если потребует­ ся применить совершенно другой подход в СМЫСЛОВОМ ЯДРЕ (CORE DOMAIN), этому по­ мешает имеющаяся крупномасштабная структура. Разработчики могут специализировать модель, но не смогут изменить СМЫСЛОВОЕ ЯДРО, не изменив одновременно и протокол для всех отличающихся компонентов. В результате процесс непрерывного совершенство­ вания ЯДРА и углубляющий рефакторинг практически остановятся .

В книге [10] дается хороший обзор "дерзких" попыток применения СРЕД ПОДКЛЮЧАЕМЫХ КОМПОНЕНТОВ (PLUGGABLE COMPONENT FRAMEWORKS) в нескольких областях. В числе других рассматривается SEMAТЕСН CIM. Такие среды пользовались переменным успехом. Самое большое препятствие к их применению, по-видимому, со­ стоит в том, что для проектирования полезной среды нужна очень глубокая степень по­ нимания проблемы. СРЕДА ПОДКЛЮЧАЕМЫХ КОМПОНЕНТОВ не должна быть ни первой,

ГЛАВА 16. КРУПНО М АСШТАБНАЯ СТРУКТУРА

ни даже второй крупномасштабной структурой, применяемой к проекту. Наиболее ус­ пешные примеры возникали тогда, когда вначале были полностью и в достаточном коли­ честве разработаны специализированные приложения .

Пример

Среда SEMATECH CIM На заводе по производству компьютерных микросхем (чипов) группы (партии) кремниевых пластин движутся от одного агрегата к другому, проходя через сотни этапов обработки, пока процесс нанесения и протравливания микроскопических электрических цепей не будет завершен. Заводу требуется программное обеспечение, которое бы умело отслеживать каждую отдельную партию, точно записывать всю выполненную над ней обработку, а затем направлять либо работников завода, либо автоматические устройства для переноса партии к следующему агрегату и применения следующего технологическо­ го процесса. Такие программы называются системами управления nроизводством, СУП (таnufасtиring ехесиtiоn system, MES) .

В ходе всего этого используются сотни разных агрегатов от десятков поставщиков, и на каждый этап работ есть четко прописанные инструкции и спецификации. Создать СУП, которая бы смогла справиться с этим нагромождением, - дело сложное и запре­ дельно дорогое. Для решения этой проблемы промышленный консорциум SEMA ТЕСН разработал среду CIM Framework .

Система CIM - очень большая и сложная, в ней много разных аспектов, но нам здесь важны два из них. Бо-первых, среда определяет абстрактные интерфейсы для базовых по­ нятий, связанных с управлением производством полупроводниковых устройств, другими словами, СМЫСЛОВОЕ ЯДРО (CORE DOMAIN) предметной области в форме АБСТРАКТНОГО ЯДРА (ABSTRACT CORE). Б этих определениях интерфейсов присутствует и функциональ­ ность, и семантика .

«Iпtеrfасе»

Machine

–  –  –

Рис. 16.24. СШlЬ1l0 уnрощеll1l0е nодМ1l0жесmво Иllmерфейсов С/М с npu.м,epa.ми реализаций Если поставщик оборудования вводит в строй новый агрегат, ему необходимо разра­ ботать специализированную реализацию интерфейса Process Machine (Технологи­ чесКИЙ агрегат). Если соблюсти все требования интерфейса, их управляющий агрега­ том компонент сможет подключаться к любому приложению, основанному на среде CIM Frarnework .

404 ЧАстьIV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Определив эти интерфейсы, SEMAТЕС Н определил и правила, по которым они мо­ гут взаимодействовать в приложении. Любое приложение на базе CI M Framework долж­ но реализовать протокол, включающий объекты, которые реализуют какое-то подмноже­ ство таких интерфейсов. Если протокол реализован, и приложение строго придержива­ ется абстрактных интерфейсов, то оно может рассчитывать на обещанный этими интерфейсами набор функций независимо от конкретной реализации. Сочетание интер­ фейсов и протокола их использования образует жесткую, существенно ограничительную крупномасштабную структуру .

Выполняется в старой системе

--------

-------

–  –  –

Рис. 16.25. Пользователь заклады вает партию nластиll в следующий агрегат и регист­ рирует их nеремещеlluе в компьютере Б среде имеются очень специфические требования к инфраструктуре. Она тесно при­ вязана к СОRБА дЛЯ обеспечения непрерывности существования данных, обработки транзакций и событий, выполнения других технических задач. Но что в ней самое инте­ ресное это определение СРЕДЫ ПОДКЛЮЧАЕМЫХ КОМПОНЕНТОВ, которая каждому по­ зволяет разрабатывать свое программное обеспечение и беспрепятственно интегрировать его в огромные существующие системы. Никто не знает всех деталей такой системы, но все понимают ее общие свойства .

*** Ка".могут тысячи людей, работая независи.мо, сделать nанно из более че.м 40 000 nанелей?

Крупномасштабная структура для мозаичного панно памяти жертв СПИДа возникла благодаря нескольким простым общим правилам, а о подробностях позаботились от­ дельные участники. Обратите внимание, что в правилах поставлена общая цель (почтить память людей, умерших от СПИДа), определяются свойства компонентов, позволяющие интегрировать их в общее целое, и задается возможность манипулировать большими фрагментами панно ( например, складывать его) .

ГЛАВА 16. КРУПНО МАСШТАБНАЯ СТРУКТУРА

Создание лоскута для панно

–  –  –

Оформление лоскута Включите в него имя человека, которого вы поминаете. Можно включить дополнительную информацию: даты рождения и смерти, место рождения... Посвятите один лоскут одному человеку.. .

Выбор материала Помните, что панно будут много раз складывать и разворачивать, так что имеет значение его долговечность. Свойства клея со временем ухудшаются, поэтому если к лоскуту нужно что-то прикрепить, это лучше пришить. Лучше всего подходит нерастягиваIОЩаяся ткань средней плотности - парусина или поплин .

Композиция может быть вертикальной или горизонтальной, но окончательный лоскут (90х180 см) с подрубленной кромкой должен иметь размеры 3 фута на 6 не более и не менее! Когда будете резать ткань, оставьте на каждой стороне лишних 5-7 см для кромки .

Если вы не сможете подрубить кромку сами, оставьте это нам. Рекомендуется сделать подкладку, не обязательно толстую - это позволяет поддерживать чистоту лоскутов при раскладывании их на земле, а также сохранять форму ткани .

Создание лоскута Для создания лоскута воспользуйтесь одним или несколькими нижеперечисленными спо­ собами .

Аппликация. На ткань основы пришиваются кусочки другой ткани, буквы, небольшие • памятные изображения. Клей использовать не нужно - он не удержится .

Краска. Нанесите рисунок текстильной краской, стойким красителем для ткани или •

–  –  –

слишком клейкие .

Трафарет. Нанесите рисунок на ткань карандашом по трафарету, поднимите его и на­ • несите окончательный рисунок кисточкой или несмываемыми чернилами .

Коллаж из предметов. Подберите не слишком объемные и тяжелые предметы из тако­ • го материала, чтобы не порвать ткань (например, стекло и блестки не подходят) .

Фотопечать. Лучше всего наносить фотографии или буквы, перенеся их на специаль­ • ные переводные картинки, которые наносятся проглаживанием горячим YTIOrOM. На­ 100% несите их на ХЛОПКОВУIО ткань и при шейте ее к основе. Фотографии можно на­ нести также на прозрачный виниловый пластик и пришить его к основному лоскуту (не в центре, чтобы их не складывали) .

Насколько жесткой должна быть структура Шаблоны крупномасштабных структур, рассмотренные в этой главе, по своей жесткости охватывают весьма широкий диапазон: от весьма вольного ОБРАЗА СИСТЕМЫ (SYSTEM METAPHOR) до строго определенной СРЕДЫ ПОДКЛЮЧАЕМЫХ КОМПОНЕНТОВ (PLUGGABLE COMPONENТ FRAMEWORK). Конечно, возможны и другие структуры. Даже в пределах общего структурного шаблона всегда есть выбор, насколько жестко определить его правила .

Например, УРОВНИ РАЗДЕЛЕНИЯ ОБЯЗАННОСТЕЙ ( RESPONSIBILITY LAYERS) диктуют способ выделения понятий модели и взаимосвязи между ними, но можно добавить и свои правила, которые будут задавать образцы взаимодействия между уровнями .

406 ЧАстьIV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Рассмотрим завод, на котором автоматизированная программная система направляет каждую деталь к нужному агрегату, где она обрабатывается согласно какому-то технологи­ ческому процессу. Определение нужного процесса поступает с уровня регламентов (policy), а выполняется он на операционном уровне. Но на нижнем, производственном, уровне неиз­ бежны ошибки. Реальная ситуация не будет соответствовать правилам, заданным в про­ грамме. Так вот, операционный уровень должен отражать реальность как она есть. Это оз­ начает, что если деталь случайно поместили не в тот агрегат, информация об этом должна быть воспринята безо всяких оговорок и условий. Эту исключительную ситуацию надо ка­ ким-то образом перенаправить на более высокий уровень, где включатся механизмы при­ нятия решений, и проблема будет решена по другим регламентам - например, деталь будет направлена в ремонт или выброшена за негодностью. Но операционный уровень ничего не знает об уровнях выше него. Обмен информацией следует организовать так, чтобы он не создавал двусторонних взаимосвязей между нижними и верхними уровнями .

Обычно оповещение подобного рода организуется через механизмы событий. Объек­ ты операционного уровня генерируют события при каждом изменении своего состояния .

А объекты уровня регламентов "прослушивают" интереСУIощие их события с нижних уровней. Если событие нарушает какое-то регламентное правило, то либо выполняется конкретное ответное действие (фигурирующее в определении правила), либо генериру­ ется событие для оповещения еще более высокого уровня .

В примере с банком стоимость активов изменяется (операционный уровень), изменяя и стоимость сегментов портфеля. Когда она превышает установленные для портфеля пределы ассигнований (регламентный уровень), посылается извещение трейдеру, кото­ рый может купить или продать активы для восстановления баланса .

Все это можно решать в рабочем порядке, но можно и установить некий согласован­ ный порядок действий, которому бы следовали все в ходе взаимодействия между объек­ тами того или иного уровня. Более жесткая структура увеличивает единообразие и об­ легчает интерпретацию архитектуры. Если структура подходит к задаче, ее регламент­ ные правила, скорее всего, будут подталкивать разработчиков к хорошей архитектуре, и отдельные части будут удачно сходиться вместе .

С другой стороны, структурные ограничения могут ударить по гибкости, которая требует­ ся разработчикам. Специфические схемы коммуникации MOryт оказаться неэффективными для реализации между разными ОГРАНИЧЕННЫМИ КОНТЕКСТАМИ (BOUNDED CONТEXTS) в неоднородной системе, особенно если используются разные технологии реализации .

Итак, следует бороться с искушением строить жесткие архитектурные среды и строго регламентировать реализацию крупномасштабной структуры. Наиболее важная заслуга крупномасштабной структуры - достижение концептуальной связности и углубление по­ нимания предметной области. Каждое структурное nравШlО должно облегчать разработку .

Структурирующий рефакторинг в эпоху, когда наша индустрия старается стряхнуть с себя оковы жесткого заблаго­ временного проектирования программ, многие сочтут крупномасштабную структуру "откатом" к старым недобрым временам "каскадной" архитектуры с односторонним по­ током данных7. Но на самом деле найти действительно полезную структуру можно толь­ ко через углубленное понимание предметной области и стоящей задачи. А практический способ достижения такого понимания - это итерационный процесс разработки .

7 Автор употребляет :метафору lf)ater/all, т.е. "водопад", который никогда не течет вверх, а толь­ ко вниз. Прu.меч. перев .

ГЛАВА 16. КРУПНО М АСШТАБНАЯ СТРУКТУРА

Группа разработчиков, стремящаяся к ЭВОЛЮЦИОННОЙ ОРГАНИЗАЦИИ модели (EVOLVING ORDER), должна бесстрашно пересматривать свою крупномасштабную струк­ туру в течение всего времени реализации проекта. Разработчики не обязаны тащить на себе структуру, порожденную в самом начале, когда никто еще не понимал предметную область или техническое задание как следует .

К сожалению, эволюция означает, что окончательная структура не будет известна на старте. Пока структура не вырисуется в своем финальном виде, будет много рефакторин­ га. Это дорого и трудно, но это необходl1..М-О. Существует несколько общих подходов, по­ зволяющих снизить стоимость при максимизации выгоды .

Минимализ м Один из ключей к удешевлению структуры - это ее простота и легкость. Не пытай­ тесь охватить все на свете. Решайте самые насущные и серьезные задачи, а остальное пусть складывается в рабочем порядке .

На ранних этапах работы бывает полезно выбрать нежесткую структуру наподобие ОБРАЗА СИСТЕМЫ (SYSTEM METAPHOR)· или нескольких УРОВНЕЙ РАЗДЕЛЕI-IИЯ ОБЯЗАННОСТЕЙ (RESPONSIBILITY LAYERS). Даже самая минималистическая и нежесткая структура дает общие подсказки, помогающие избежать хаоса .

Коммуникативность и самодисциплина Следовать структуре как при написании нового кода, так и при рефакторинге должна вся группа. Для этого вся группа должна ее понимать. Терминология и описания взаимо­ связей внутри структуры должны войти в ЕДИНЫЙ язык (UBIQUITOUS LANGUAGE) .

Крупномасштабная структура может породить словарь общих понятий, облегчающий проекту связь с системой, а разным разработчикам - единообразие в принятии решений .

Но большинство таких структур имеют нежесткий, концептуальный и рекомендатель­ ный характер, поэтому в группе разработчиков должна царить самодисциплина .

Если не все участники в достаточной мере привержены структуре, она имеет тенден­ цию к разложению. Взаимосвязь структуры с теми или иными конкретными частями модели или реализации обычно не слишком очевидна в коде программы, и функцио­ нальные тесты от структуры не зависят. К тому же структура имеет тенденцию быть аб­ страктной, так что единообразие разработки бывает нелегко соблюсти в большом кол­ лективе (или нескольких коллективах) .

Коммуникативный уровень дискуссий, практикуемый в большинстве групп разра­ ботчиков, недостаточен для поддержания в системе согласованной крупномаСIIlтабной структуры. Критически важно инкорпорировать ее в ЕДИНЫЙ язык проекта и приучить всех сотрудников постоянно пользоваться этим языком .

Реструктуризация дает гибкую архитектуру Любое изменение в структуре может вызвать необходимость масштабного рефакто­ ринга. Структура эволюционирует по мере возрастания сложности системы и углубле­ ния ее понимания. Каждый раз, когда структура меняется на другую, необходимо менять всю систему, чтобы nрисnособить ее к новому порядку. Очевидно, это нем алый труд .

Но все не так плохо, как кажется. Мне случалось убедиться, что архитектуру, в кото­ рой есть крупномасштабная структура, трансформировать во что-то новое гораздо легче, чем такую, где ее нет. Это верно даже для тех случаев, когда сам тип структуры изменя­ ется на другой - например, от ОБРАЗА ( METAPHOR) мы переходим к УРОВНЯМ (LAYERS) .

ЧАстьIV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Я не могу полностью объяснить этот феномен. Частично ответ состоит в том, что рест­ руктуризировать нечто легче тогда, когда понимаешь, как оно устроено в текущий мо­ мент, а наличие структуры облегчает такое понимание. Частично дело в дисциплине, ко­ торой требует поддержание структуры - ее наличие отражается на всех аспектах систе­ мы. Но есть и нечто большее, думается мне. Дело в том, что изменять систему, в которой ранее сменилось уже две крупномаСII1табных структуры, - еще легче .

Новая кожаная куртка - слишком жесткая и неудобная, но после первого дня ее но­ Пlения локти, разогнувшись и согнувшись много раз, становятся подвижнее. Еще за не­ сколько дней "разнашиваются Ilлечи", и куртку становится легче надевать. Через не­ сколько месяцев кожа становится гибкой и податливой, а куртка - удобной и легкой .

Похоже, именно так обстоит дело и с моделями, которые несколько раз подвергались ра­ зумным преобразованиям. В них закладывается постоянно пополняющаяся база знаний, определяются и "nро'Качиваются" основные направления изменений, тогда как стабильные аспекты упрощаются. В структуре модели вырисовываются наиболее общие КОНЦЕПТУАЛЬНЫЕ КОНТУРЫ предметной области, лежащей в ее основе .

Дистилляция Еще один важнейший этап при создании модели - это непрерывная дистилляция .

Она облегчает изменение структуры сразу несколькими способами. Прежде всего, в ходе нее механизмы, НЕСIIЕЦИАЛИЗИРОВАННЫЕ ПОДОБЛАСТИ (GENERIC SUBDOMAINS) и дру­ гие вспомогательные структуры выносятся вовне из СМЫСЛОВОГО ЯДРА (CORE DOMAIN), после чего там попросту остается меньше материала для реструктуризации .

Если это возможно, вспомогательные элементы следует определять так, чтобы они встраивались в крупномасштабную структуру как можно проще. Например, в системе УРОВНЕЙ РАЗДЕЛЕНИЯ ОБЯЗАННОСТЕЙ (RESPONSIBILITY LAYERS) можно так определить НЕСПЕЦИАЛИЗИРОВАННУЮ ПОДОБЛАСТЬ (GENERIC SUBDOMAIN), что она поместится в один уровень. Если реализуются ПОДКЛIОЧАЕМЫЕ КОМПОНЕНТЫ (PLUGGABLE COMPONENTS), то такая подобласть может принадлежать целиком к одному компоненту или же быть ОБЩИМ ЯДРОМ (SHARED KERNEL) для набора родственных компонентов. Возможно, эти вспомога­ тельные элементы придется подвергнуть рефакторингу, чтобы найти им подходящее место в структуре. Но они развиваются независимо от СМЫСЛОВОГО ЯДРА (CORE DOMAIN) и имеют тенденцию к более узкой специализации, что облегчает задачу. В конечном счете, они еще и не настолько критичны, чтобы их усовершенствование так уж много значило .

Принципы дистилляции и углубляющего рефакторинга применимы и к крупномас­ штабной структуре. Например, из начально уровни структуры могут быть выбраны на основе поверхностного знания предметной области; затем они постепенно заменяются более глубокими абстракциями, которые выражают фундаментальные задачи, решаемые системой. Отточенная четкость представления помогает разработчикам глубже понимать архитектуру системы, в чем и состоит цель структуризации. Но это не только цель, а еще в какой-то мере и средство, поскольку благодаря ей манипуляции с системой в глобаль­ ном масштабе становятся легче и безопаснее .

ГЛАВА 16. КРУПНОМАСШТАБНАЯ СТРУКТУРА

ГЛАВА 17

–  –  –

В предыдущих трех главах было представлено множество принципов и приемов стратегического предметно-ориентированного проектирования (DDD). Созда­ вая архитектуру большой и сложной системы, часто приходится "пускать" в ход сразу несколько из них. Как крупномасштабная структура может сосуществовать с КАРТОЙ КОНТЕКСТОВ (CONTEXT МАР) ? Как сочетаются друг с другом отдельные "кирпичики"?

С чего следует начинать? Какой должен быть первый шаг? А третий? Как вообще взять­ ся за разработку собственной стратегии?

Сочетание крупномасштабных структур и ограниченных контекстов Сочетание крупномасштабных структур и ограниченных контекстов

–  –  –

Рис. 17. 1 .

Три основополагающих принципа стратегического проектирования (контекстность, дистилляция, крупномасштабная структура) не заменяют, а дополняют друг друга и на­ ходятся в разных формах взаимодействия. Например, крупномасштабная структура мо­ жет существовать в пределах одного ОГРАНИЧЕННОГО КОНТЕКСТА (BOUNDED CONTEXT), а может распространяться сразу на несколько и являться организующим началом для (CONTEXT МАР) .

КАРТЫ КОНТЕКСТОВ

Приведенные ранее примеры УРОВНЕЙ РАЗДЕЛЕНИЯ ОБЯЗАННОСТЕЙ (RESPONSIBILITY LA YERS) были ограничены одним КОНТЕКСТОМ. Так легче всего объяснить основную идею, и именно таково основное применение этого шаблона. В этом простом сценарии смысловые значения имен уровней сосредоточены в одном и том же КОНТЕКСТЕ, как и имена элементов модели или интерфейсов подсистем, существующих внутри этого КОНТЕКСТА .

-..... .

----

-----

–  –  –

...... .

---- -- -Рис. 17.2. Сmрукmуризация модели в пределах одuого ОГРАНИЧЕННОГО КОНТЕКСТА Подобная локальная структура может быть полезна в очень сложной, но унифициро­ ванной и единой модели; она поднимает уровень сложности до тех пределов, в каких сис­ тему еще можно держать в рамках одного КОНТЕКСТА .

НО во многих проектах возникает более сложная и важная задача: понять, как стыку­ ются между собой разные по смыслу части. Пусть даже они разделены на несколько раз­ ных KOf-IТЕКСТОВ, но какую роль каждая из частей играет в целостной системе и как эти части соотносятся одна с другой? В этом случае для организации КАРТЫ КОНТЕКСТОВ может использоваться крупномасштабная структура. В таком случае терминология структуры будет применима во всем проекте (или по крайней мере в четко очерченной его подобласти) .

Предположим, вы хотите ввести УРОВНИ РАЗДЕЛЕНИЯ ОБЯЗАННОСТЕЙ (RESPONSIBI­ LITY LAYERS), но у вас имеется старая система, организация которой несовместима с же­ лаемой крупномасштабной структурой. Нужно ли отказываться от мысли о введении УРОВНЕЙ? Нет, но нужно правильно определить место, которое в этой структуре будет занимать старое приложение. Для этого бывает полезно как-то охарактеризовать это приложение, дать ему определение. Предоставляемые им услуги могут на самом деле ограничиваться одним-двумя УРОВНЯМИ. Если вы можете сказать, что старая система целиком помещается в такой-то УРОВЕНЬ (или УРОВНИ) РАЗДЕЛЕНИЯ ОБЯЗАННОСТЕЙ, это означает, что вы сумели кратко определить ключевую роль и сферу применения этой системы .

–  –  –

Рис. 17.4. Структура, в которой 1-lеКОmОрblМ KOMn01-lе1-lmам позволяется расnростра1-lЯтъся 1-la uесколъко уровuей Если обращение к функциям старой системы реализовано через ФАСАДНЫЕ МЕТОДЫ (FACADE), то есть все шансы, что каждую из фасадных СЛУЖБ (SERVICES), которая стаГЛАВА 17. ОБЪЕДИНЕНИЕ СТРАТЕГИЧЕСКИХ ПОДХОДОВ вится В соответствие этим функциям, можно спроектировать так, чтобы она попадала целиком в один уровень .

Внутреннее устройство приложения по координированию поставки (Shipping Coor­ dination), которое в данном примере является устаревшим, представлено в виде единой массы, где деталей устройства не видно. Но в проекте, где присутствует четкая крупно­ масштабная структура, простирающаяся через несколько ОГРАНИЧЕННЫХ КОНТЕКСТОВ, разработчики могут принять решение упорядочить свою модель в пределах своего КОНТЕКСТА по тем же самым, хорошо знакомым им УРОВНЯМ .

–  –  –

Рис. 17.5. Та же структура, nрuмеuеuuая и вuутри контекста, и в рамках всей КАРТЫ КОНТЕКСТОВ Конечно, каждый ОГРАНИЧЕННЫЙ КОНТЕКСТ находится в своем собственном про­ странстве имен, и поэтому в пределах одного КОНТЕКСТА можно ввести одну структуру, а в пределах соседнего - другую, а всю КАРТУ организовать в соответствии с третьей. Но если слишком увлечься подобными вещами, можно обесценить саму идею крупномас­ штабной структуры как набора понятий, унифицирующего проект .

Сочетание крупномасmтабной СТРУКТУРЫ и ДИСТИЛЛЯЦИИ Понятия крупномасштабной структуры и дистилляции также взаимно дополняют друг друга. Крупномасштабная структура может помочь в объяснении взаимоотношений в пределах СМЫСЛОВОГО ЯДРА (CORE DOMAIN), а также между НЕСПЕЦИАЛИЗИРОВАН­

НЫМИ ПОДОБЛАСТЯМИ (GENERIC SUBDOMAINS) .

В то же время и сама крупномасштабная структура может являться важной частью СМЫСЛОВОГО ЯДРА. Например, если выделить уровни потенциала, операций, регламентов и поддержки принятия решений, это само по себе дистиллирует такое знание, которое явЧАстьIV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОБАНИЕ ляется фундаментальным для решения той прикладной проблемы, для которой и пишется программное обеспечение. Это знание особенно полезно, если проект поделен между не­ сколькими ОГРАНИЧЕННЫМИ КОНТЕКСТАМИ (BOUNDED CONTEXTS), так что объекты СМЫСЛОВОГО ЯДРА модели не имеют прямого значения для большей части проекта .

–  –  –

Рис. 17.6. Модули СМЫСЛОВОГО ЯДРА (СОRБ DOMAIN) и llЕСПЕЦИАЛИЗИРОВА1IНЫЕ ПОДОБЛАСТИ (GENER1C SUBDOMAINS) вы являются четче в многоуровневой структуре ПервоначВльная оценка Выполняя стратегическое проектирование в проекте, начните с четкой оценки теку­ щей ситуации .

1. Начертите КАРТУ КОНТЕКСТОВ. Можно ли это сделать естественным способом, или есть препятствие в виде неоднозначности?

2. Обратите внимание на использование языка в проекте. Существует ли в нем (UBIQUITOUS LANGUAGE)? Достаточно ли он богат, чтобы помочь ЕДИНЫЙ ЯЗЫК в процессе разработки?

–  –  –

5. Обладают ли разработчики достаточными техническими навыками?

6. Хорошо ли разработчики знают саму предметную область? Вызывает ли она у них интерес?

Идеальных ответов, конечно, найти не удастся. В настоящий момент вы знаете о про­ екте гораздо меньше, чем будете знать в будущем. Но все-таки эти вопросы дают хоро­ шую "отправную точку". К моменту, когда вы получите на них пусть и первоначальные, но конкретные ответы, у вас уже выработается представление о том, что нужно сделать в первую очередь. С течением времени эти ответы можно усовершенствовать·· особенно КАРТУ КОНТЕКСТОВ, ВВЕДЕНИЕ В ПРЕДМЕ ТНУЮ ОБЛАСТЬ и другие материалы проекта для отражения изменившейся ситуации и новых знаний .

Кому планировать стратегию В традиционной методике архитектура создается еще до начала разработки приложе­ ния и спускается сверху группой, у которой больше полномочий, чем у непосредствен­ ных разработчиков. Но так работать не обязательно - и получается, честно говоря, не слишком эффективно .

Стратегическое проектирование по самому своему определению должно применяться к проекту в целом. Существует много способов организации проектов, и мне не хотелось бы сводить все к слишком конкретным рецептам. Тем не менее, чтобы процесс принятия проектных решений давал результаты, необходимо знать кое-какие основы .

Вначале давайте бросим беглый взгляд на два стиля работы, которые, по моему опыту, да­ ют практически полезные результаты (и проигнорируем старый подход "мудрость свыше") .

Самозарождение структуры в ходе разработки Группа с должной самодисциплиной, состоящая из хорошо контактирующих друг с другом разработчиков, может работать без "централизованной власти" и придти к не­ коему общему набору принципов путем ЭВОЛЮЦИОННОЙ ОРГАНИЗАЦИИ ( EVOLVING ORDER). Порядок в этом случае органично развивается, а не навязывается .

Это типичная модель работы в экстремальном программировании. Теоретически структура может возникнуть совершенно спонтанно в результате интеллектуального прорыва любой из пар программистов. Но чаще бывает, что унифицированную крупно­ масштабную структуру помогает поддерживать один человек или группа людей, имею­ IЦая на это некие контрольные полномочия. Особенно хорошо этот подход работает, если подобный неформальный лидер - еще и практикующий разработчик, который умеет правильно судить и общаться, а не только выдавать идеи. В знакомых мне группах экс­ тремального программирования лидерство по стратегическому проектированию часто возникало спонтанно и переходило, например, к коучу1. Но кем бы ни был этот естест­ венный лидер, он все-таки остается и членом группы разраБО1(1ИКОВ. Отсюда следует, что 1 Coach это тренер, преподаватель, инструктор и Т.п. Но так уж устоялось в экстремальном

–  –  –

ЧАстьIV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОБАНИЕ во всей группе разработчиков должно быть как минимум несколько работников такого уровня для принятия проектных решений, которые повлияют на весь проект в целом .

Когда крупномасштабная структура распространяется на несколько групп разработ­ чиков, тесно связанные группы могут перейти к неформальным видам взаимодействия .

В такой ситуации каждая из групп способна делать открытия, ведущие к воплощению идеи крупномасштабной структуры, но конкретные варианты обсуждаются неформаль­ ным комитетом, составленным из представителей разных групп. После оценки влияния архитектурного решения участники могут решить принять, изменить или отвергнуть его .

Группы пытаются двигаться вперед совместно, в такой вот неформальной связке. Это возможно, когда взаимодействующих групп сравнительно немного, когда они мотивиро­ ваны на взаимное координирование усилий, когда их навыки проектирования сравнимы, а потребности в структурировании приложения настолько сходны, чтобы их удовлетво­ рила одна крупномасштабная структура .

Смежная группа по разработке архитектуры Если разработка стратегии ведется совместно несколькими группами, возникает же­ лание иметь какую-то централизацию в принятии решений. Дискредитировавшая себя модель восседающего в вышине архитектора - не единственный возможный вариант .

Группа проектирования архитектуры может действовать на равных правах с другими разработчиками, помогая им координировать и приводить в согласие их крупномас­ штабные структуры и границы ОГРАНИЧЕННЫХ КОНТЕКСТОВ (BOUNDED CONTEXTS), а также решать другие технические проблемы, представляющие общий интерес. Чтобы приносить пользу в таком контексте, проектировщики архитектуры должны настроиться на практическую разработку приложения .

Б организационной диаграмме такая группа может походить на традиционную груп­ пу разработки архитектуры, но на деле она отличается во всех аспектах своей работы .

Члены такой группы реально работают совместно с непосредственными разработчиками, прорабатывают вместе с ними шаблоны и формы, экспериментируют с целью дистилля­ ции - в общем, не боятся марать руки .

Я встречал подобное пару раз. В подобных проектах главный архитектор обычно склонен делать все то, что перечислено далее в списке .

Шесть принципов принятия решений при стратегическом проектировании Ре шения должны доводиться до всех членов lpYnnbI Очевидно, если не все участники проекта знают стратегию и следуют ей, то она оказы­ вается вообще ни при чем. Чтобы этого не случилось, разработчики склонны организовы­ ваться вокруг централизованных групп проектирования архитектуры с официальными "властными" полномочиями, -- чтобы гарантировать следование одним и тем же норматив­ ным правилам. По иронии судьбы, архитекторов, запершихся в высоких кабинетах, чаще всего игнорируют, а их указания обходят. Собственно, у разработчиков и нет другого выхо­ да, когда в результате отсутствия обратной связи с архитекторами попытки применить их требования к реальным приложениям кончаются совершенно нереальными схемами .

В проекте с высоким уровнем коммуникации стратегическое архитектурное проекти­ рование в исполнении группы разработки имеет более реальный шанс получить всеобГЛАВА 17. ОБЪЕДИНЕНИЕ СТРАТЕГИЧЕСКИХ ПОДХОДОВ щее распространение. Такая стратегия будет иметь связь с жизнью, а соответствующие полномочия помогут в принятии коллективных решений .

Какова бы ни была система, следует меньше беспокоиться об уровне полномочий, исхо­ дящем от руководства, чем о реальной взаимосвязи между разработчиками и стратегией .

В nроцессе nринятия решений следует учитывать обратную связь Чтобы выработать организующий принцип, крупномасштабную структуру или дос­ таточно тонкую дистилляцию, необходимо глубоко пони мать цели и задачи проекта, а также понятия его предметной области. Единственные люди, которые обладают должной глубиной познаний - это члены группы разработки. Это объясняет, почему архитектуры приложений, построенные специальными архитектурными группами, так редко бывают полезными, несмотря на несомненный талант архитекторов .

В отличие от разработки технической инфраструктуры и архитектуры, стратегиче­ ское проектирование не подразумевает написания больших объемов кода, хотя и влияет на весь процесс разработки. А вот активное участие всех групп разработчиков оно как раз подразумевает. Опытный архитектор обладает умением слушать идеи, исходящие от различных людей, и способствовать выработке общего решения .

Одна из технических архитектурных групп, с которой я работал, постоянно посылала своих членов на работу в другие группы разработки, где пользовались их средой и биб­ лиотеками. Благодаря такой ротации кадров в архитектурную группу поступал реальный опыт решения проблем, стоявших перед разработчиками, а к разработчикам - знания о тонкостях применения среды. Именно такая тесная обратная связь и требуется в процес­ се стратегического проектирования .

План должен допуск ать эволюцию, развитие Эффективная разработка программного обеспечения - это очень динамичный про­ цесс. Если на самом верхнем уровне принятия решений все уже "высечено в камне", раз­ работчикам остается меньше вариантов выбора в тех случаях, когда они вынуждены реа­ гировать на изменения. ЭВОЛЮЦИОННАЯ ОРГАНИЗАЦИЯ (EVOLVING ORDER) позволяет избежать этой ловушки, поскольку требует непрерывных изменений в крупномасштаб­ ной структуре по итогам углубления знаний о предмете .

Если слишком много проектных решений жестко принимается заранее, разработчики оказываются "стреноженными" и не могут гибко реагировать на те проблемы, которые перед ними ставятся. Так что принцип, приводящий приложение к единообразию - это ценно и хорошо, но он должен меняться и развиваться по мере реализации проекта, а также не отнимать слишком много возможностей у разработчиков, которым и так при­ ходится нелегко .

Если в проекте присутствует тесная обратная связь, то при возникновении препятст­ вий в ходе разработки возникают также и неожиданные возможности, и даже инновации .

Разработчики архитектуры не должны nере.м.анивать к себе лучшие кадры Проектирование на этом уровне требует такой интеллектуальной подготовки, какая есть у немногих. Руководители имеют привычку переводить наиболее технически спо­ собных разработчиков в группы проектирования архитектуры и инфраструктуры, пото­ му что хотят найти их квалификации наилучшее применение среди ОПЫТН\IХ проекти­ ровщиков. Со своей стороны разработчиков привлекает возможность более активно вли­ ять на проект или заниматься "более интересными" задачами. Да и быть членом элитной группы уже престижно само по себе .

Таким образом, для реальной текущей разработки приложения часто остаются лишь наименее технически подготовленные программисты. Но для разработки тоже требуются 418 ЧАстьIV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ хорошие навыки проектирования, иначе затея обречена на провал. Даже если стратеги­ ческая группа спроектирует хорошую архитектуру, у разработчиков может не оказаться должной подготовки для ее реализации .

В противоположность уже сказанному, в такие группы почти никогда не включаются разработчики, которые не так искушены технически, но имеют самые обширные знания предметной области. Стратегическое проектирование - это не чисто техническая задача;

размежевание с программистами, имеющими глубокие знания по предмету, ограничива­ ет возможности архитекторов. И специалисты из самой предметной области, кстати, то­ же нужны .

Важно иметь сильных проеКТИРОВUJ;ИКОВ во всех группах разработчиков. А в каждой группе, которая занимается стратегическим проектированием, необходимо иметь доста­ точно знаний по предметной области. Иногда бывает просто необходимо нанять допол­ нительно лучших проектировщиков-архитекторов. Бывает, что архитектурную группу достаточно привлечь на частичную занятость. В общем, вариантов может быть много, но любая эффективная группа стратегического проектирования должна иметь в партнерах не менее эффективную группу технической разработки .

В стратегическом nроектировании нужны минимализм и скромность Дистилляция и минимализм важны для любой хорошей архитектуры, но в стратеги­ ческом проектировании минимализм еще важнее. Даже мелкая нестыковка может при­ вести к проблемам. Специально выделенным архитектурным группам следует соблюдать осторожность, поскольку они хуже чувствуют препятствия, возникающие благодаря их деятельности перед разработчиками. В то же время энтузиазм архитекторов, порождае­ мый их широкими полномочиями, часто уводит их куда-то в сторону. Я это не только видел много раз, но и сам бывал грешен. Одна хорошая идея цепляется за другую, и в конце концов получаем перегруженную архитектуру, работаЮUJ;УЮ против нас же .

Вместо этого необходимо дисциплинировать себя и произвести на свет организую­ щие принципы и ключевые модели, очищенные от всего, что не помогает улучшить чет­ кость и ясность архитектуры. По правде говоря, практически любой элемент чему-то да мешает, поэтому любая мелочь должна иметь веское обоснование своего существования .

Требуется скромность, чтобы признать, что даже самая лучшая ваша идея для кого-то может являться препятствием .

Объекты - для специализации, разработчики - для обобщения Сущность хорошего объектно-ориентированного проектирования состоит в том, что­ бы дать каждому объекту четкие и узкоспециализированные обязанности, снизив взаи­ мозависимость с другими объектами до абсолютного минимума. Иногда мы пытаемся и взаимодействие в группах выстроить так же аккуратно, как в самом приложении. Но в хорошем проекте всегда находится много людей, которым интересны дела других. Разра­ ботчики экспериментируют с архитектурными средами. Архитекторы пишут код прило­ жений. Все оБUJ;аются со всеми. Фактически, царит хаос. Пусть специализация будет присуща объектам, а разработчики должны заниматься обобщением .

В этой книге я подчеркнул различие между стратегическим nроектироваl-Lием и дру­ гими его видами, чтобы прояснить особенности решаемых в процессе задач. Теперь же необходимо отметить, что двумя разными видами проекjирования вовсе не обязаны за­ ниматься две разных категории людей. Построить гибкую архитектуру на основе углуб­ ленной модели - это сложная проектная деятельность, но подробности в ней так важны, что это должен делать кто-то, непосредственно работающий с кодом. Стратегическое проектирование вырастает из проектирования конкретных программных структур, и все

ГЛАВА 17. ОБЪЕДИНЕНИЕ СТРАТЕГИЧЕСКИХ ПОДХОДОВ

же оно требует целостного, масштабного видения всей проектной деятельности - может быть, даже деятельности нескольких групп разработчиков. Программисты обожают на­ ходить способы так "нарезать" задачи, чтобы архитекторы не обязаны были понимать предметную область, а специалисты в этой области не должны были бы разбираться в технологии реализации. Конечно, есть предел у способности отдельного человека осво­ ить некую деятельность, но сверхспециализация лишает предметно-ориентированное проектирование самой его сути и силы .

То же вер но и для тех нических сред проектирования Технические архитектурные среды (frameworks) могут сильно ускорить разработку приложения, в том числе и уровня его предметной области, предоставив для этой цели готовый уровень инфраструктуры. Благодаря этому приложение освобождается от необ­ ходимости реализовать основные технические службы. Кроме того, предметная область изолируется от других задач. Но есть и риск, что техническая архитектура окажет влия­ ние на выразительную СМЫСЛОВУ10 реализацию модели предметной области u внесет из ­ менчивость. Это может произойти даже тогда, когда проектировщики архитектурной среды вовсе не имеют намерения вмешиваться в уровни предметной области или при­ кладных операций .

Те же требования, которые устанавливают планку для стратегического проектирова­ ния, могут помочь и в разработке технической архитектуры. Эволюционность, минима­ лизм, тесное сотрудничество с непосредственными разработчиками могут породить по­ стоянно совершенствующийся набор технических служб и правил, реально помогающих в разработке и ничем не мешающих. Архитектуры, которые не следуют этому принципу, либо снижают творческую активность разработчиков, либо просто игнорируются и об­ ходятся, отчего разработка приложения практически лишается всякой архитектурной составляющей .

Существует один подход, следование которому гарантированно убивает техническую архитектурную среду разработки .

Не пишите архитектурные сре ды для "чайников " Если делить разработчиков на группы, подразумевая при этом, что некоторые из них неспособны к архитектурному проектированию, то впереди, скорее всего, вас ждет не­ удача, поскольку этим недооценивается сложность технической разработки приложения .

Если вы считаете, что у этих людей не хватает ума проектировать, нечего поручать им разработку программ. А если ума у них хватает, тогда нянчиться с ними - это только ставить преграды между ними и требующимися им для работы инструментами .

Такой подход приводит к проблемам и во взаимоотношениях между группами. Мне приходилось оказываться в числе таких снобов, после чего извиняться перед программи­ стами в каждой беседе за группы, в которые я входил. ( Изменить что-либо в такой груп­ пе мне, боюсь, не удалось.) Следует отметить, что инкапсуляция несуществеН1lЫХ теmическux деталей резко от ­ личается от того вида заблаговременной структуризации, который я терпеть не могу .

Техническая среда разработки может вложить в руки разработчика мощные абстракции и программные средства, освобождая его от тяжелой рутины. Трудно описать эту разни­ цу в каком-то обобщенном виде, но все же ее можно обозначить следующим способом .

Попросите создателей среды ответить, чего они ожидают от пользователя их сре­ ды/компонента/инструментального средства. Если они высоко оценивают уровень ква­ лификации пользователя среды, то, скорее всего, находятся на правильном пути .

420 ЧАсть IV. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Долой генеральный пл ан Группа архитекторов (тех, которые проектируют реальные здания), возглавляемая Кристофером Александером (Christopher Alexander), отстаивала принцип постепенного, пошагового роста в архитектуре и градостроительстве. Они очень хорошо объяснили, почему генеральные планы проваливаются .

Не имея 1lекоего nроцесса nлаllироваllИЯ, совершеll1l0 llевОЗМОЖ1l0 когда -либо придать ОрегОllСКОМУ Уllиверситету (University ol Oregon) такой глубокий и гаРМОllИЧllЫЙ архитектУРllЫЙ порядок, как тот, что лежит в ОС1l0ве строеllИЙ Кембриджского Уllиверситета (University 01 Cambridge) .

Подобllые проблемы всегда решались разработкой геllераЛЬ1l0го nлаllа. В та ­ ком nлаllе пытаются дать достатОЧ1l0 тОЧllые указаllИЯ, чтобы обеспечить едИllство среды в целом, и все же оставить место для адаптации отделыlхx здаllИЙ и участков nростра1lства к MeCтllbl.М, llужда:м, .

...и все раз1l00браЗllые части этого будущего Уllиверситета образуют едИ1l0е, свЯЗ1l0е целое, поскольку все 01lИ просто вставляются в ячейки-гllезда едИ1l0Й архитектуры .

... 1lа nрактике геllералыlйй nлаll терпит nоражеllие - потому что 01l созда ­ ет тоталитарllЫЙ порядок, а 1lе естествеllllЫЙ. ГеllераЛЬ1l0МУ nлаllУ nрису ­ ща ИЗЛИШ1lЯя "жесткость ", 01l 1lе может адаптироваться к ecтeCтвellllbl.М, и llеnредсказуемы.м, измеllеllИЯМ, которые llеизбеЖllЫ в ЖИЗllИ сообщества. Как только nодобllые измеllеllИЯ случаются... геllералыlйй nлаll устаревает, и ему больше 1lе следуют. Но даже в той мере, в какой геllnлаllУ все-таки сле ­ дУ10т... та:м, llедостатОЧ1l0 говорится о связях между зда llИЯМИ, llаселеll1l0сти, сбалаllсироваll1l0сти ФУllКЦИЙ и т.n., чтобы 01l мог помочь каждому ме ­ ст1l0МУ строительству или объекту архитектуры хорошо вписаться в ок ­ ружаЮЩУ10 среду как в едИ1l0е целое .

... Поnытка идти этим курсом llаnОМИllает, скорее, "заnОЛllеllие " цветов в детской Кllижке -раскраске... В лучшем случае порядок, вОЗllикающий в ре ­ зультате такой процедуры, баllалеll .

...Итак, в качестве истОЧllика оргаllИЧ1l0го, естестве1l1l0го порядка геllераль ­ llЫЙ nлаll од1l0време1l1l0 и слишком точеll, и llедостатОЧ1l0 точеll. Все в целом зада1l0 слишком жестко, тогда как детали оnределеllы lедостаточ1l0o тОЧ1l0 .

... 1lаличие геllераЛЬ1l0го nлаllа отталкивает пользователей объекта, [поскольку по оnределеllИЮJ члеllЫ ЖИЛИЩ1l0го сообщества практически 1lе могут влиять 1lа свои будущие ЖИЛИЩllые условия ведь БОЛЬШИllство са ­ мых ваЖllЫХ nроектllЫХ решеllИЙ уже nРИ1lЯто .

Из Кllиги " The Oregon Experimen t", [1 J Вместо генерального плана Александер и его коллеги отстаивали такой подход, как набор nРИllциnов, действующий в отношении всех членов сообщества и применяемый при любом мелком, локальном акте застройки, чтобы в результате возник " органичный порядок", хорошо приспособленный к реальным обстоятельствам .

ГЛАВА 17. ОБЪЕДИНЕНИЕ СТРАТЕГИЧЕСКИХ ПОДХОДОВ

ЗАКЛЮЧЕНИЕ Р аботать над интересным проектом, экспериментировать с новыми идеями и мето­ дами - такой опыт всегда приносит большое удовлетворение. И все же я считаю его бесплодным, если получающееся в результате программное обеспечение не находит практического и эффективного применения. Реальная проверка успеха программы - это проверка временем, т.е. ее служба на протяжении некоторого периода времени. И мне дове­ лось наблюдать за "судьбой" некоторых моих прошлых проектов в течение многих лет .

Здесь будут рассмотрены пять таких проектов. В каждом из них предпринималась серьезная попытка предметно-ориентированного проектирования (domain -driven design), пусть даже несистематическая и, конечно, не под этим названием. Во всех этих проектах были разработаны программы; только в некоторых удалось продержаться до конца и по­ строить архитектуру по модели .

Программа автоматизированного проектирования печатных плат из главы 1 имела оглушительный успех у бета-пользователей в этой области. К сожалению, инновацион­ ная компания, которая запустила этот проект, потерпела полное поражение в своей ры­ ночной деятельности и была в конце концов ликвидирована. А сама программа в на­ стоящее время используется горсткой инженеров-схемотехников, у которых сохрани­ лись старые копии от бета-тестирования. Как и всякое оставленное без сопровождения программное обеспечение, она будет работать до тех пор, пока в одну из программ, с ко­ торыми она интегрирована, не внесут какое-нибудь роковое для нее изменение .

Не давно пос аженные оливковые деревья

Программа по управлению кредитованием из главы 9 существовала и развивалась примерно по тому же пути около трех лет после качественного скачка, о котором я писал .

Затем в какой-то момент этот программный проект отделился в виде независимой ком­ пании. В суматохе реорганизации из проекта "выжили" человека, который руководил им с самого начала, и многие ключевые разработчики УIlIЛИ вместе с ним. Новая группа разработчиков придерживалась несколько другого подхода к проектироваНИIО, не столь тес­ но нривязанного к идеям объектного моделирования. Но они все же сохранили четко выIаженныый уровень предметной области с реализацией сложных операций и продол­ жали поощрять приобретение разработчиками знаний о предметной области. Через семь лет после отделения проекта программа продолжает "обогащаться" новыми функциями .

Это " ЛИДИРУIОlцее приложение" в своей области, обслуживаЮllее все большее количест­ во организаций-клиентов и дающее основной поток прибыли компании .

Пока предметно-ориентированный подход не приобрел более IIIИРОКОЙ популярности, интересные программы во многих проектах разрабатываются за довольно короткие проме­ жутки времени с ударной производительностью труда. Впоследствии такой проект пре­ враlцается в нечто более-менее обыкновенное, где нет возможности в полной мере исполь­ зовать силу углубленных и дистиллированных моделей, не говоря уже о совершенствова­ нии в этом направлении. Но, хотя я бы желал от этих проектов большего, на самом деле они оказались очень успешными и приносят практическую пользу в течение многих лет .

Сем ь лет спустя

Над одним проектом я работал в паре с другим разработчиком; мы писали утилиту, которая была IIужна клиенту для производства его ключевого продукта. Функции этой утилиты были довольно сложными и хитро скомбинированными. Мне нравилось рабо­ тать над проектом; мы разработали гибкую архитектуру с АБСТРАКТНЫМ ЯДРОМ (ABSTRACT CORE). Когда программу передали заказчику, на этом всякое участие разра­ ботчи ков в ее судьбе закончилось. По причине такого резкого разрыва я полагал, что специ(l)ические свойства архитектуры, позволявшие комбинировать элементы програм­ мыI' могут оказаться малопонятными, и их заменят более типичной вариантной логикой .

Но вначале этого не случилось. Когда мы сдавали программу клиенту, в пакет входил полны1й набор тестов и документ по дистилляции. Новые разработчики ВОСПОЛIзовались им, чтобы сориентироваться в своих поисках, и по мере освоения продукта им все боль­ ше нравились возможности, предоставляемые архитектурой. Когда я услышал их заме­ чания год спустя, я понял, что в новой группе сохранился и продолжил развиваться наш lIре)кний единый язык (UBIQUITOUS LANGUAGE) .

Затем, еIце через год, я услышал у)ке ДРУГУIО историю. Разработчики столкнулись с новыми требованиями, возможности удовлетворить которые в рамках унаследованной архитектуры они не нашли. Им пришлось изменить архитектуру практически до неузна­ ваемости. Выяснив некоторые подробности, я понял, что "изящное" реIнение возникших задач было бы невозможно из-за некоторых аспектов пашей модели. Именно в такие МОЛКJIЮЧЕНИ Е менты становится возможным качественный скачок к более углубленной модели - осо­ бенно тогда, когда, как в данном случае, разработчики накопили глубокие знания и по­ нимание предметной области - в результате они изменили и модель, и архитектуру .

Мне эту историю рассказывали осторожно, дипломатично, ожидая, как мне кажется, разочарования с моей стороны из-за того, что столь большая часть моей работы оказа­ лась "отброшена". Но я не слишком привязан к своим архитектурным произведениям .

Успешная архитектура не обязана сохраняться вечно. Постройте систему, поставьте л·ю ­ дей в зависимость от нее, сделайте ее непрозрачной, и она будет существовать вечно, как неприкосновенное наследие прошлого. Углубленная же модель допускает ясное видение, дающее новое знание, а гибкая архитектура помогает в изменениях. Модель, которую они в итоге построили, оказалась глубже, лучше приспособлена к реальным запросам пользователей. Их архитектура решала реальные проблемы. Программному обеспече­ нию свойственно изменяться, и эта программа продолжала развиваться .

Примеры, посвященные управлению поставками/перевозками и разбросанные по всей книге, более или менее основаны на проекте для большой международной компа­ нии, занимаЮllейся контейнерными перевозками. С самого начала руководство проекта выбрало за основу предметно-ориентированный подход, но так и не развило культуру программирования, которая послужила бы ему "питательной средой". За разработку мо­ дулей взялось сразу несколько групп программистов весьма разной квалификации в об­ ласти проектирования и объектного моделирования, координирование же их осупеств­ лялось только неформальным общением между руководителями групп, а также архитек­ турной группой, ориентированной на заказчика. И нам удалось разработать достаточно глуБОКУIО модель СМЫСЛОВОГО ЯДРА ( CORE DOMAIN) предметной области, а также рабо­ тоспособный единый язык ( UBIQUITOUS LANGUAGE) .

НО культура, принятая в организации, яростно сопротивлялась итерационному про­ цессу разработки, и мы слишком задержались с выпуском работающей внутренней вер­ сии. Поэтому проблемы стали видны только на позднем этапе, когда исправлять их уже было рискованно и дорого. В какой-то момент мы обнаружили в модели специфические аспекты, ТОРМОЗИВIIIие быстродействие в базе данных. В ПРОЕКТИРОВАНИИ ПО МОДЕЛИ ( MODEL-DRIVEN DESIGN) совершенно естественно двигаться от проблем в реализации к изменениям в модели, но к тому времени у нас было чувство, что мы уже слишком да­ леко зашли, чтобы вносить изменения в фундаментаЛЬНУIО модель. Вместо этого измене­ ния вносились в код, чтобы повысить его эффективность, и связь кода с моделыо все ос­ лаблялась. Первая версия приложения также выявила наличие ограничений на масшта­ бируемость в технической инфраструктуре, которые повергли руководство в панику .

Для решения инфраструктурных проблем были привлечены специалисты, и проект не­ сколько "выровнялся". Но цикл реализации и моделирования предметной области так и не стал замкнутым .

Некоторые группы разработали прекрасные приложения со сложными функциями и выразительными моделями. Другие произвели на свет нечто жесткое и застывшее, в ко­ тором модель была сведена к структурам данных, хотя даже в этом случае какие-то следы ЕДИНОГО ЯЗЫКА сохранялись. Возможно, КАРТА КОНТЕКСТОВ (CONТEXT МАР) могла бы оказать решающую помощь, поскольку конечные продукты1 разных групп находились в довольно хаотическом отношении друг с другом. И все же модель ЯДРА, заКЛlоченная в ЕДИНОМ ЯЗЫКЕ, помогла разработчикам в конечном счете "склеить" систему воедино .

Хотя и реализованный в неполном объеме, проект все-таки заменил собой несколько устаревших систем. Одно целое удерживалось BlVlecTe благодаря наличи·ю общего набора понятий, хотя большую часть архитектуры нельзя было назвать достаточно гибкой. К на­ СТОЯllему времени, многие годы спустя, это приложение частично и само устарело, хотя ЗАКЛЮЧЕНИЕ до сих пор обслуживает потребности глобального бизнеса. Хотя влияние более успеш­ ных групп разработчиков неизбежно распространяется со временем, как раз времени-то может и не хватить, даже в самой процветающей компании. В культуру проекта ПРОЕКТИРОВАНИЕ ПО МОДЕЛИ так и не вошло окончательно. Новые разработки теперь ведутся на других платформах, и наша прежняя работа влияет на них только косвенным образом - тогда, когда новые разработчики должны приспосабливаться к старым ком­ понентам системы .

В некоторых кругах относятся подозрительно к амбициозным целям наподобие тех, которые изначально поставила себе компания по перевозкам. Есть мнение, что лучше писать небольшие программы, с которыми можно легко управиться, лучше придержи­ ваться наименьшего общего знаменателя в архитектуре и делать все просто. Что ж, этот консервативный подход имеет право на существование и удобен при реализации сроч­ ных проектов с четко очерченной областью применения. Но интегрированные, основан­ ные на сложных моделях, системы обещают то, на что эти быстрые разработки не спо­ собны. Существует и третий путь. Предметно-ориентированное проектирование (DDD) позволяет расширять большие системы с богатыми функциональными возможностями поэтапно, постепенно развивая углубленную модель и гибкую архитектуру .

Я завершу свой разговор упоминанием о компании Evant, которая разрабатывает программы для управления материальными запасами. Я играл в их проекте второсте­ пенную, вспомогатеЛЬНУIО роль, всего лишь делая свой скромный вклад в уже и без того высокую культуру проектирования. Об этом проекте писали как о "рекламном лице" экстремального программирования; при этом обычно не отмечалось, что в проекте была очень сильная предметно-ориентированная составляющая. Дистиллировались все более глубокие модели, они находили свое выражение во все более гибких архитектурах. Про­ ект хорошо развивался до краха "доткомов" в 200 1 году. После этого из-за постоянной нехватки капиталовложений начались сокращения, разработка программ замерла, и ка­ залось, что уже близок конец. Но летом 2002 года на Evant вышла одна из десяти круп­ нейших в мире компаний розничной торговли. Этому потенциальному клиенту нравился сам программный продукт, но в нем требовалось доработать архитектуру, чтобы иметь возможность масштабирования на огромну·ю операцию по планированию товарно­ материальных запасов. Это был последний шанс для Evant .

Группа разработчиков, хоть и сократившаяся до четырех человек, все еще имела кое-что в запасе. У них была квалификация, знание предметной области, а у одного из членов груп­ пы - еще и опыт по части масштабирования. У них была очень эффективная культура про­ граммирования. А еще у них была база кода с гибкой архитектурой, которая облегчала вне­ сение изменений. Тем летом эти четверо разработчиков предприняли героические усилия, получив в результате возможность манипулировать миллиардами единиц планирования и сотнями пользователей. Благодаря силе этих возможностей фирма Evant заполучила в клиенты настоящего "монстра", а чуть позже была куплена другой фирмой, желавшей при­ способить их программы и проверенные возможности к новым требованиям .

Пи всем этом культура предметно-ориентированного программирования (равно как и культура экстремального программирования) пережила эпоху перемен и возродилась вновь .

В настоящее время и модель, и архитектура продолжают эволюционировать. Кстати, разра­ ботчики Evant не ассимилировались в компании-покупателе, а, наоборот, стимулировали ее группы разработчиков следовать своему примеру. Так что их история продолжается .

Ни в одном проекте никогда не будут применены сразу все методы, описанные в этой книге. Но даже при этом любой проект, в основе которого лежит DDD, можно узнать сразу по нескольким признакам. Его опредеЛЯЮllая характеристика это акцент на изуЗАКЛЮЧЕНИЕ чение и понимание предметной области с последующим внедрением полученных знаний в приложение. Все остальное проистекает отсюда. Все члены рабочей группы сознатель­ но пользуются языком проекта и культивиру·ют его усовершенствование. Их трудно удовлетворить качеством модели предметной области, потому что они все время узнают из этой области что-то новое. Они считают непрерывное усовершенствование модели вполне нормальным, а плохо "подогнанную" модель - опасной. Они всерьез относятся к навыкам проектирования, потому что не так-то легко разработать программное обеспе­ чение прикладного профессионального уровня, которое бы четко отражало предметну·ю область. Они преодолевают препятствия и идут дальше .

Взгляд в будущее Климат, экосистемы, биология в недавнем прошлом считались хаотическими, неточ­ ными областями знания в противоположность таким наукам, как физика или химия .

Однако в последнее время люди осознали, что мнимая "хаотичность" на самом деле пре­ доставляет широчайшие перспективы для обнаружения и понимания порядка в этих очень сложных явлениях. "Сложность" - это понятие, находящееся на переднем крае многих наук. Хотя наиболее интересными и трудными для решения инженеры­ программисты всегда считали чисто технологические, системные задачи, предметно­ ориентированное проектирование открывает новую область для исследований, которая в сложности ничуть им не уступит. Прикладное программное обеспечение не должно быть нагромождением кое-как связанных вместе компонентов. Превращение сложной области знания в стройную и обозримую программную архитектуру - это главная цель для тех­ нически грамотных программистов .

Еще очень далеки мы от тех времен, когда любой неспециалист сможет легко разраба­ тывать работоспособные программы. Армия программистов с примитивными навыками, конечно, сумеет написать какое-то программное обеспечение, но вряд ли такое, которое спасет компанию в ответственный момент. Разработчикам (утилит, пакетов, библиотек, сред и Т.Д.) неплохо бы переориентировать свои усилия на новую цель: как помочь та­ лантливым программистам расширить свои возможности и повысить производитель­ ность труда. Необходимы четкие методы исследований моделей предметных областей и выражения их в работаIОЩИХ прикладных программах. С нетерпением жду возможности поэкспериментировать с новыми средствами и технологиями, созданными для этой цели .

Но, хотя новые средства разработки и будут оценены по достоинству, нельзя зацик­ ливаться на них и терять из виду простую истину: разработка хороших программ - это дело, требующее обучения и мышления. Для моделирования нужны воображение и са­ модисциплина. Средства, которые помогают нам думать и не отвлекаться, - это хорошо .

А вот попытки автоматизировать то, что должно быть продуктом мышления - наивны и контрпродуктивны .

Имея в руках нынешние средства и технологии разработки, уже можно строить сис­ темы значительно более полезные и работоспособные, чем это делается в большинстве нынешних проектов. Можно писать программы, которыми приятно пользоваться и кото­ рые приятно совершенствовать, такие, которые способствуют развити·ю новых возмож­ ностей и пополняют интеллектуальный капитал их владельцев .

ЗАКЛЮЧЕНИЕ ПРИЛОЖЕНИЕ

–  –  –

м оя первая "хорошая машина", доставшаяся мне вскоре после окончания кол­ леджа, -- восьмилетний "Пежо", который иногда называли французским " Мерседесом". Машина была хорошо сделана, ее было приятно водить, и в свое время она показывала высокую надежность. Но к моменту попадания в мои руки она уже достигла возраста, когда начинаются серьезные проблемы и требуется постоянное техобслужива­ ние и ремонт .

Компания Peugeot имеет долгую историю, она прошла собственный путь эволюции в течение многих десятилетий. В ней пользуются своей собственной механической терми­ нологией, а ее проектные решения весьма необычны; даже распределение функций между частями механизма часто бывает нестандартным. В результате создаются машины, рабо­ тать с которыми могут только специалисты компании, что для владельца - молодого выпу­ скника колледжа с весьма скромным доходом - может представлять проблему .

Как-то я повез машину к местному механику, чтобы разобраться с утечкой жидкости .

Он заглянул под днище и сообщил, что "вытекает масло из небольшой коробки, находя­ щейся примерно на одной трети длины машины, считая сзади; эта коробка, кажется, име­ ет отношение к распределению торможения между передним и задним мостом". После этого механик предложил поехать на фирменную техстанци'Ю, находившуюся в восьми­ десяти километрах. А вот с "Фордом" или "Хондой" справился бы всякий, поэтому эти машины намного удобнее и дешевле содержать, пусть даже в механическом отношении они устроены не менее сложно .

Я любил свою машину, но никогда больше не стал покупать необычных автомобилей .

Настал день, когда обнаружилась особенно дорогостоящая проблема, и этого с меня было довольно. Я отвез свою "Пежо" в местную благотворительную организацию, которая принимала автомобили в качестве пожертвований. Затем я купил старую подержанную Honda Civic примерно за ту же сумму, в которую обошелся бы ремонт прежней машины .

Стандартных элементов архитектуры недостаточно для подробной проработки пред­ метных областей, так что всякая модель предметной области и соотвеТСТВУЮllая про­ граммная реализация всегда трудны для понимания. Более того, каждой группе разработ­ чиков приходится заново изобретать велосипед (а также коробку передач и "дворники" ло­ бового стекла). В мире объектно-ориентированного программирования все представляет собой объект, ссылку или сообщение - и это, конечно, полезная абстракция. Но для разум­ ного сужения диапазона проектных решений, а также для экономического анализа модели предметной области этого недостаточно .

Остановиться на утверждении "все есть объект" - это все равно что строителю или архитектору сказать о доме: "все есть комната". В доме есть комната с высоковольтными розетками и раковиной-мойкой, в которой можно готовить еду. Есть маленькая комната на втором этаже, где lVI0ЖНО спать. Чтобы полностыо описать обычный жилой дом, потребуется много страниц. Люди, которые строят дома и живут в них, понимают, что ком­ наты следуют определенным образцам (шаблонам) со специально придуманными име­ нами, - такими как "кухня". Используя этот язык, можно обсуждать экономические ас­ пекты проектирования и строительства домов .

Далее, не всякая комбинация функций может оказаться практически полезной. Почему бы не устроить комнату, где можно и мыться, и спать? Вот удобно было бы. Но долгий опыт, перешедший в обычай, тем не менее предписывает отделять "спальни" от "ванных" .

Оборудование ванных комнат совместно используются болыпим количеством людей, чем обстановка спален. К тому же в ванной требуется максимальное уединение - даже от лю­ дей, которые пользуются той же спальней. Для ванных комнат имеются специальные и до­ рогостоящие инфраструктурные требования. Ванны и унитазы часто ставятся в одном по­ мещении - санузле - именно потому, что для них требуется одна и та же инфраструктура (подвод воды и канализация), и пользуются ими в одинаковом уединении .

Еще одно помещение, к которому выдвигаются особые инфраструктурные требова­ ния - это помещение, где готовят пищу, и называется оно "кухня". В противоположность санузлу, на кухне никакого особого уединения не требуется. Из-за дороговизны оборудо­ вания она обычно одна в доме, даже довольно большом. Это свойство отвечает и нашим устоявшимся обычаям совместного приготовления и приема пищи .

Если я говорю, что мне нужен дом с тремя спальнями, двумя санузлами и кухней от­ крытой планировки, я вкладываю в это короткое предложение огромное количество ин­ формации, а также избегаю множества дурацких ошибок, - например, установки унита­ за рядом с холодильником .

В проектировании чего угодно - домов, автомобилей, гребных лодок или программ мы следуем образцам-шаблонам, работоспособность которых уже проверена в прошлом, и импровизируем только в заданных пределах. Иногда, конечно, приходится изобретать нечто совершенно новое. Но, основывая стандартные элементы на шаблонных образцах, мы не тратим силы на задачи, решения которых известны, чтобы можно было сосредоточиться на наших необычных потребностях. Кроме того, работа с известными шаблонами помогает избегать проектов настолько необычных и причудливых, что их даже трудно описать .

Проектирование архитектуры предметных областей в программировании пока не столь традиционная область деятельности, как другие виды проектирования, и его раз­ нообразие подчас не позволяет применять в работе настолько конкретные шаблоны, как образцы автомобильных запчастей или комнат дома. Тем не менее и в нем есть потреб­ ность пойти дальше утверждения "все есть объект" как минимум до того этапа, когда от­ личают болты от гаек .

Способ обмена проектными знаниями и их стандартизации был предложен в 1 970-е годы группой архитекторов под руководством Кристофера Александера (Cristopher Al­ exander), см. [2 ]. Их "язык описания шаблонов" (pattern language) свел воедино ряд проверенных и работающих проектных решений распространенных задач (и гораздо бо­ лее тонко, чем мой пример с кухней, от которого некоторые читатели Александера, ско­ рее всего, поморщились бы). Цель создания этого языка состояла в том, чтобы строители и пользователи общались на нем между собой, руководствуясь шаблонами-образцами для создания красивых зданий, которые бы хорошо служили и нравились людям .

Что бы там сами архитекторы ни думали об этой идее, язык описания шаблонов ока­ зал большое влияние на проектирование и разработку программных продуктов. В 1 990-х годах архитектурные шаблоны программирования уже применялись с переменным успе­ хом в разных областях, особенно в детальном рабочем проектировании [ 1 4 ] и при созда­ нии технических архитектур [ 7 ]. В более поздние времена шаблоны использовались для документирования базовых приемов объектно-ориентированного программирования

–  –  –

Итоговый контекст: краткое объяснение, как от текущего шаблона возможен переход к последующим .

[ Обсуждение трудностей реализации. В исходном формате Александера это обсужде­ ние было бы помещено в раздел, где описывается решение проблемы, и часто в этой кни­ ге я следую этому принципу. Но для некоторых шаблонов требуется более обстоятельное обсуждение их реализации. Чтобы сократить центральную часть обсуждения до мини­ мума, длинные подробные обсуждения выносятся за пределы описания шаблона .

Туда же часто выносятся длинные примеры, особенно те, в которых используется сразу несколько шаблонов.]

ИСПОЛЬ З ОВАНИЕ ШАБЛОНОВ В ЭТО Й КНИГЕ 43 1

ГЛОССАРИЙ Здесь приводятся краткие определения некоторых терминов, названий архитектурных шаблонов и других понятий, употребляемых в книге1 • Агрегат (aggregate). Совокупность ассоциированных друг с другом объектов, воспри­ нимаемых с точки зрения изменения данных как единое целое. Внешние ссылки возможны только на один объект АГРЕГАТА, именуемый корневым (root). В границах АГРЕГАТА дейст­ вует определенный набор правил согласования и единообразия .

Аналитический шаблон (analysis pattem). Группа понятий, в совокупности пред­ ставляющих некоторое общепринятое построение в прикладном моделировании. Может относиться к одной предметной области или распространяться на несколько [ 1 1 ] .

Контрольное утверждение (assertion). Утверждение о правильном состоянии про­ граммы в определенной точке, независимо от способа его достижения. Обычно КОНТРОЛЬ­ НОЕ УТВЕРЖДЕНИЕ задает результат операции или инвариант элемента архитектуры .

Ограниченный контекст (bounded context). Область применения конкретной модели с определенными границами. ОГРАНИЧЕННЫЕ КОНТЕКСТЫ дают членам группы разра­ ботчиков четкое и общее представление о том, где следует соблюдать согласованность, а где можно работать независимо .

Клиент (client). Элемент программы, который обращается к проектируемому эле­ менту (вызывает его) для использования его функциональных возможностей .

Связность (cohesion). Логическая согласованность и взаимозависимость .



Pages:     | 1 |   ...   | 2 | 3 || 5 |



Похожие работы:

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное автономное образовательное учреждение высшего образования "Национальный исследовательский Томский политехнический университет" Инженерная школа Природных ресурсов Отделение Нефтегазового дела Направление 21.03.01 Нефтегазовое дело Пр...»

«Министерство образования и науки Российской Федерации Федеральное государственное автономное образовательное учреждение высшего профессионального образования "НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ" Инженерная школа новых произво...»

«Министерство образования и науки Российской Федерации ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ "САРАТОВСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ГОСУДАРСТВ...»

«нестационарной постановке. // Вторая конференция молодых ученых УралЭНИН. Екатеринбург: УрФУ, 2017.7. Богданец С.В., Скороходов А.С. Оптимизация работы газотранспортной системы путем разработки сменной проточной части для нагнетателя природного газа // Вторая конференция молодых ученых УралЭНИН. Екатеринбург: УрФУ, 2017.8. Седун...»

«№ 14, 05.03.2010 ОГЛАВЛЕНИЕ 1 РАЗДЕЛ ПЕРВЫЙ ПРАВОВЫЕ АКТЫ РЕШЕНИЯ ПЕРМСКОЙ ГОРОДСКОЙ ДУМЫ 25.02.2010 № 13-д О досрочном прекращении полномочий главы администрации города Перми5 25.02.2010 № 25 О внесении изменений в решение Пермской городской Думы от 22.12.2009...»

«ГОСТ 19251.7-93 МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ ЦИНК МЕТОДЫ ОПРЕДЕЛЕНИЯ АЛЮМИНИЯ Издание официальное БЗ 8 -9 6 МЕЖГОСУДАРСТВЕННЫЙ СОВЕТ ПО СТАНДАРТИЗАЦИИ, МЕТРОЛОГИИ И СЕРТИФИКАЦИИ Минск строительство дачного дома ГОСТ 19251.7-93 Предисловие 1 РАЗРАБОТАН Восточным научно-исследовательским горн...»

«Выпуск 15. ПОРОДОРАЗРУШАЮЩИЙ И МЕТАЛООБРАБАТЫВАЮЩИЙ ИНСТРУМЕНТ – ТЕХНИКА И ТЕХНОЛОГИЯ ЕГО ИЗГОТОВЛЕНИЯ И ПРИМЕНЕНИЯ металлообрабатывающий инструмент – техника и технология его изготовления и применения. – К.: ИСМ им. В....»

«Распределение учебного времени дисциплины Общая трудоемкость дисциплины 3 зачетных единицы, 108 часа Номер семестра Всего Виды учебной нагрузки, часы часов Лекции 12 12 Практические занятия 8 8 Самос...»

«tssN 1999-8465 Science Intensive Technotogies 7, 2015, т. 16 В номере: Организация обмена данными в дублированных вычислительных комплексах Экспериментальное исследование сверхмногоцикловой усталости титановых сплавов и др. те л./ф а к с: (495) 62...»

«Министерство образования и науки Российской Федерации Государственное образовательное учреждение высшего профессионального образования "МОСКОВСКИЙ ФИЗИКО-ТЕХНИЧЕСКИЙ ИНСТИТУТ (государственный университет)" ПРИКАЗ От 13 сентября 2010 г. № 622-1 г. Долгопрудный О проведении 53-й научной конференции МФТИ 1. Пр...»

«Хотяновский Дмитрий Владимирович ЧИСЛЕННЫЙ АНАЛИЗ СВЕРХЗВУКОВЫХ ТЕЧЕНИЙ СО СЛОЖНЫМИ УДАРНО-ВОЛНОВЫМИ СТРУКТУРАМИ 01.02.05 — механика жидкости, газа и плазмы Автореферат диссертации на соискание ученой степени кандидата физико-математических наук Новосибирск 2007 Работа выполнена в Институте теоретической и прикладной механики и...»

«Ректор СПбПУ провел пресс-конференцию о предстоящем юбилее вуза Сегодня в ТАСС прошла пресс-конференция, посвященная 120-летию СанктПетербургского политехнического университета Петра Великого. О взаимодействии науки, образования и производства, о том, какие праздничные мероприятия ожидают гостей и сотруднико...»

«Национальный правовой Интернет-портал Республики Беларусь, 02.11.2017, 8/32482 УТВЕРЖДЕНО Постановление Министерства образования Республики Беларусь 06.09.2017 № 123 Типовая программа дополнительного образования детей и молодежи...»

«MP 48 r УФ-/LED-сушилка для ногтей Инструкция по применению РУССКИЙ Внимательно прочтите данную инструкцию по применению, сохраните ее для последующего использования, храните ее в месте, доступном для других пользователей, и следуйте ее указаниям. Содержание 1. Испол...»

«Комплекс технических средств диспетчеризации "Кристалл" Исходные данные для проектирования Версия 0015 от 07.11.18 СДК Кристалл -2СОДЕРЖАНИЕ Введение 1. Комплекс "Кристалл-S/S1" 2. Основные технические данные 2.1. Составные части комплек...»

«ОБЩИЕ СВЕДЕНИЯ О СИСТЕМЕ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ P-CAD Современные технологии разработки и создания радиоэлектронных устройств и схем используют специальные программные средства, позволяющие разрабатывать микросхемы, радиочастотные устройства (волно...»

«Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования "САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ЛЕСОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ имени С. М. Кирова" Кафедра технологии материалов, конструкций и сооружений из древесины А. Н. Чубинский, доктор техниче...»

«УДК 621.313(075.8) ББК 31.261я73 У 91 МИНОБРНАУКИ РОССИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ "ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СЕРВИСА" (ФГБОУ ВО "ПВГУС") подготовк...»

«ISSN 2079-5459 (print) СЕРІЯ НОВІ РІШЕННЯ В СУЧАСНИХ ТЕХНОЛОГІЯХ ISSN 2413-4295 (online) УДК 519.6: 612.172.4 doi:10.20998/2413-4295.2018.26.20 MATLAB МОДЕЛЬ ГЕНЕРАТОРА ЭКГ СИГНАЛА НА ОСНОВЕ ЧАСТОТНОГО ПРЕОБРАЗОВАНИЯ М. А. ШИШКИН1*, О. А. БУТОВА1, Л. В. ФЕТЮХИНА1, Е. Б. АХИЕЗ...»

«Информационная справка. Конкурс "УМНИК-НТИ" в рамках Программы "УМНИК". Программа "УМНИК". Программа "УМНИК" (далее – Программа) Фонда содействия развитию малых форм предприятий в научно-технической сфере (далее – ФСИ, Фонд) направлена на...»

«Абубакр Али Фатхи Габер Математическое моделирование динамики магнитной частицы во внешнем поле 05.13.18 – Математическое моделирование, численные методы и комплексы программ Автореферат диссертации на соискание ученой степени кандидата физико-математических наук Екатеринб...»

«У Т В Е РЖ Д А Ю Генеральный директор АО НПК "Северная заря" _ /Е.Д. Малахов/ 2017г. ИНФОРМАЦИЯ О ЗАКУПКЕ Азотной ловушки, форвакуумного насоса, фильтра масляного тумана и картриджа. Предмет закупки: Азотная ловушка, форвакуумный насос, фильтр масляного ту...»

«ОПИСАНИЕ ТИПА СРЕДСТВ ИЗМЕРЕНИЙ Модули для измерения активной Внесены в Государственный реестр средств измерений и реактивной энергии Регистрационный № 28510-07 переменного тока ЕМЗ Взамен № 28510-05 Выпускаются по ГОСТ Р 52320-2005, ГОСТ Р 52323-2005, ГОСТ Р 5...»







 
2019 www.librus.dobrota.biz - «Бесплатная электронная библиотека - собрание публикаций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.