DDD: Реализуем проект Вавилонская башня (Максим Цепков, Software People 2012)

Короткая ссылка: BabelTower

Ссылки сюда (2) →

Приветствие конференции

По просьбе организаторов для сайта конференции.

Максим Цепков - Software Man с 1985 года

Добрый день, дорогие друзья и коллеги!

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

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

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

До встречи на Software People 2012!

Тезисы доклада

Как известно, Вавилонская башня не была построена потому, что бог создал разные языки и люди перестали понимать друг друга. Реализация больших IT-проектов нередко терпит крах по той же причине: заказчики и разработчики говорят на разных языках и не понимают друг друга. Domain-Driven Design (DDD) решает эту проблему с помощью проектирования на основе модели, которая описывается и обсуждается на едином языке (ubiquitous language), понятном всем участникам проекта. Это открывает дорогу к успешному воплощению грандиозных IT-проектов.

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

Применение DDD дает следующие преимущества.

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

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

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

Презентация

Нажмите чтобы посмотреть или получить pdf

Краткое изложение

Теоретическая часть

Как известно, вавилонская башня не была построена потому что Бог смешал языки и люди перестали понимать друг друга. Реализация больших IT-проектов терпит крах по той же причине: заказчики и разработчики говорят на разных языках и не понимают друг друга. Domain Driven Design (DDD) решает эту проблему через проектирование на основе модели, описываемой и обсуждаемой на едином языке, понимаемом всеми участниками проекта. Это открывает дорогу к успешному воплощению грандиозных IT-проектов.

Когда говорят о DDD, то обычно сосредотачивают внимание на разработке с помощью моделей. На самом деле, проектирование и разработка на основе моделей появилась давно. Поэтому DDD часто и воспринимают как новый бренд для давно известных техник. Однако, новаторство DDD заключается в другом. А именно, в использовании единого языка (ubiqutos launguage). Этот язык понимают все участники проекта. Он используется как для описания предметной области, так и для описания модели. Это позволяет обойтись при DDD единой моделью, вместо двух отдельных моделей - для предметной области, описанной на ее языке и для IT-системы, описанной на языке IT. В результате обеспечивается качественное упрощение процесса проектирования, а также возможность верификации модели системы бизнес-специалистами заказчика, что открывает дорогу к успешной реализации сложных проектов автоматизации.

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

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

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

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

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

Наша компания успешно использует DDD при проектировании учетно-аналитических систем для коммерческих фирм и банков. Большой опыт работы и разнообразие проектов позволило нам существенно обогатить саму методологию. Во-первых, мы нашли графический образ для учетных моделей - диаграммы учета. Диаграммы позволяют эффективно представлять учет, делая его понятным всем участникам проекта, в том числе - далеким от бухгалтерии. Во-вторых, у нас сложилась типовая комплексная модель учетно-аналитической системы, состоящая из трех компонент: объектной модели, модели документооборота и учетной модели. Использования типовой модели позволяет переносить проектные решения между различными областями.

Практическая часть

Виза на документы

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

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

Моделью в данном случае является реализация конкретного шаблона для конкретного документа. Существуют два основных шаблона:

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

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

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

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

И это - часть выработки единого языка.

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

Долг клиента

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

Представления бизнес-специалистов о долге клиента таковы.

• Менеджеры по продажам рассматривают долг в контексте управленческих решений. Долг увеличивается как только отдано распоряжение об отгрузке, и наоборот, уменьшается как только менеджер признал возврат или претензию от клиента. Если у клиента много юридических лиц, то их интересует общая сумма долга, он легко может зачесть аванс на другой контракт, если это важно для движения сделки, при условии, что на момент завершения сделки "все сойдется", но не обязательно до копеек.
• Бухгалтеры рассматривают долг клиента с точки зрения учета по ПБУ. А в этом контексте - важно оформление документов и прохождение процедур. Долг увеличивается в момент перехода права собственности, который может быть различен, а при возврате - после надлежащей приемки товара или признания претензии. При сопоставлении отгрузок и оплат принимаются во внимание реквизиты сделок - юридические лица и контракты. И по завершенной сделки не должно оставаться расхождений даже на малые суммы.

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

• Надежное сопоставление обоих долгов возможно только при завершении сделок с клиентом, когда последствия ошибок в учете уже сложно устранить. Практически сопоставление часто выливается в ручное сравнение двух списков операций изменения долга из двух систем, и хорошо, если их количество невелико, а суммы и основные атрибуты совпадают.
• Бухгалтерский долг сложно использовать для контроля за управленческим учетом, а менеджеры часто склонны занижать долг для получения бонусов.
• Руководство компании имеет две различные суммы долга, и не может полагаться ни на одну из них при принятии управленческих решений.
• Для сверки долга с клиентом и решения проблемных ситуаций, которая бы была значимой для бухгалтерии, менеджерам приходится разбираться с тонкостями ПБУ. Или эту сверку проводят бухгалтеры, как правило, не имеющие налаженных контактов у клиента.

Обычный подход к проектированию и реализации через декомпозицию системы не решает указанной проблемы. Функционалы менеджеров по продажам и бухгалтерии оказываются в рамках различных подсистем, проходят верификацию у разных бизнес-специалистов и реализуются независимо. Конечно, в системе обычно возникает единый журнал документов, фиксирующих основные бизнес-события, однако их отбор для бухгалтерских и управленческих отчетов производится по различным критериям, о согласованности которых при развитии системы заботятся не всегда. И как следующий шаг - на документах появляются специальная пометка "только для бухгалтерии" и "не учитывать в бухгалтерии", с помощью которых и предлагается урегулировать особые ситуации. По сути, различие в языках воспроизводится в системе. И это приводит в проблемах при эксплуатации системы, о которой мы слышали у ряда фирм - менеджеры не понимают, почему система показывает какой-то долг, рассчитанный по бухгалтерским правилам, хотя у них в Excel все хорошо - а от них требуют еще и согласовать это с клиентом. Или наоборот, бухгалтеры сетуют, что у них в 1C никак не получается уверено получать цифры, имеющиеся в управленческой системе, и каждая разборка превращается в проблему. Проблема возникает и у аналитиков и разработчиков: похорошему, каждое изменение документооборота должно адекватно отражаться в обоих видах учета, но менеджеры, делая заказ на доработку, не всегда понимают - нужно ли это отражать в бухгалтерии и как, и наоборот.

Как решается эта проблема применением DDD?

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

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

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

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

Коммунальный биллинг

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

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

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

Заключение

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

Об авторе

Максим Цепков – соучредитель и главный архитектор компании CUSTIS, в которой работает со дня основания (1996). Закончил с отличием МФТИ, имеет авторские свидетельства.

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

Максим активно участвует в развитии внутренних процессов и совершенствовании практик применения гибких методологий разработки и коллективного проектирования в CUSTIS.

---

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