6931
правка
Изменения
м
Нет описания правки
Презентация [http://www.slideshare.net/custisppt/custis-tsepkovsecr2011 на slideshare]
<big>'''DDD — DDD — эффективный способ работы в условиях системной сложности'''</big>
Описывается успешный опыт применения принципов DDD при разработке больших и сложных ИТ-систем. Упор делается на построение единой модели предприятия и системы, описанной на языке, понятном всем участникам проекта, в том числе бизнес-специалистам.
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.
{{remark|Из отзывов ''[http://twitter.com/#!/avivanov/status/131638880150634496 Понравился доклад Макса Цепкова на #secr2011. Вернул мне веру в то, что кто-то до сих пор серьёзно применяет моделирование и с пользой)]'' Твиттер от [http://twitter.com/#!/avivanov Андрея Иванова], COO JetBrains}} =Краткие тезисы=
В докладе описывается применение методов Domain Driven Design (DDD) при проектировании и разработке ИТ-систем для больших предприятий, которым свойственна системная сложность. В этом случае бизнес-модель предприятия, модель ИТ-системы и сама система неизбежно будут очень сложными конструкциями, и обеспечить их соответствие в условиях изменений бизнес-процессов практически невозможно. Кроме того, эти модели, а следовательно, и устройство системы не могут быть до конца понятыми бизнес-специалистами. Это влечет дополнительные риски для разработчика (поскольку модель не может быть качественно верифицирована бизнесом) и значительно усложняет дальнейшую работу бизнес-специалистов с системой.
Эффективно работать в условиях системной сложности помогает применение принципов 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.
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.
