DDD - эффективный способ работы в условиях системной сложности (Максим Цепков на SECR-2011)

Короткая ссылка: DDD and system complexity

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

Доклад сделан на SECR-2011 02.11.2011 
Презентация на slideshare

DDD — эффективный способ работы в условиях системной сложности

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

DDD as an effective method of work in conditions of system complexity

The report describes application of DDD methods to development of complex IT systems. The essence is to construct the single model of company and system described with ubiquitous language clear for all project participants, including business-specialists.

Из отзывов Понравился доклад Макса Цепкова на #secr2011. Вернул мне веру в то, что кто-то до сих пор серьёзно применяет моделирование и с пользой) Твиттер от Андрея Иванова, COO JetBrains

Краткие тезисы

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

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

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

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

Annotation

The presentation describes application of the Domain-Driven Design (DDD) methods to software design and development for large companies, which possess system complexity. In this case business model of company, model of IT system and system itself are inevitably very complex and it is practically impossible to guarantee their correspondence. In addition, these models and consequently the structure of the system could be hardly understood by business specialists. This causes additional risks for software company (because the model could not be entirely verified by business) and makes further work with such system more complicated for business specialists.

Application of the DDD principles helps to work effectively in conditions of system complexity. It means constructing the single model of company and system and describing it with ubiquitous language, which could be easily understood by all the participants of the project: business experts, analysts, developers and end-users. This enables business specialists to verify the model and to plan changes in the system independently, without attraction of highly skilled architects and business analysts.

We successfully apply described approach for development of corporate applications. Constructing single model we use diagrams of three types (of classes, of accounting and of states) and describe them using business terms. These diagrams are transparently reflected in the system, up to the use of the same terms in the interface.

Thus, DDD makes possible successful work in conditions of system complexity due to the use of ubiquitous language and construction of the single model, which is understandable for all participants of the project, including specialists from the business side.

Развернутое изложение

Проблема

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

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

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

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

Решение

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

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

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

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

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

Практика

Как бы ни были важны теоретические подходы, гораздо большее значение имеет их успешное применение в практической деятельности. Как говорится, «теория без практики мертва». Мы успешно применяем методы DDD к разработке корпоративных приложений. При этом для построения единой модели мы используем:

• диаграммы классов (для представления объектной структуры документов и справочников);
• диаграммы учета (для отражения учета в системе);
• диаграммы состояний (для представления документооборота как основы реализации бизнес-процессов и связи документов с учетом).

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

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

Заключение

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

Об авторе

Докладчик

Максим Цепков

Максим Цепков – соучредитель и главный архитектор компании CUSTIS, в которой работает со дня основания (1996). Закончил с отличием Факультет управления и прикладной математики Московского физико-технического института, имеет авторские свидетельства. Основная область профессиональных интересов – создание архитектуры корпоративных и банковских информационных систем, поиск баланса между общими архитектурными подходами и реализацией специфических требований заказной разработки для поддержки уникальных бизнес-процессов клиентов.

Максим Цепков является экспертом в области бизнес- и системного анализа, занимается развитием шаблонов и технологий проектирования, разработкой методик применения диаграмм. Под руководством Максима и при его непосредственном участии разработано несколько технологических платформ, на которых строятся проекты CUSTIS. Максим выступает основным идеологом и создателем архитектурного шаблона для информационных систем – «Учетной машины» и диаграмм планов счетов для отображения и проектирования учета. Эти технологии применяются во всех проектах компании для банков и предприятий.

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

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

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

In english

Maxim Tsepkov is a co-founder and the chief software architect of CUSTIS since 1996, he has master degree from Moscow Institute of Physics and Technology, Control/Management and Applied Mathematics department, has many author’s certificates. The main author’s area of interests is the architecture of enterprise information systems, especially searching for balance between the common architecture patterns and practice of specific customized development for unique business processes.

Maxim Tsepkov is an expert in business and system analysis, deployment and development architecture patterns, models and diagrams. Many CUSTIS projects based on several frameworks that developed under the guidance of Maxim Tsepkov. He is the main designer of the application patterns for information system named as Accounting Engine and accounting diagrams, used for visualization and desining of accounting. This technologies used in all company’s projects for business. In fact, Maxim contributes to most of company’s projects. He is competent in design of distributed systems, system integration, and graceful deployment process, when new system gradually replaced the old system without any business-process disturbance.

Maxim contributes to evolution of agile software development process in company and practice of team software design. He is an active of professional conferences and author of various publications in CIO magazines.

---

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