|
|
| Строка 1: |
Строка 1: |
| − | Доклад на конференции [http://addconf.ru/ Application Developers Days 29-30.04 Питер]
| + | #перенаправление [[Необъектные модели предметной области. Опыт CUSTIS (Максим Цепков, ADD-2011)]] |
| − | | + | |
| − | [http://www.slideshare.net/custisppt/custis-tsepkovadd2011 Презентация] | + | |
| − | | + | |
| − | == Тезисы доклада ==
| + | |
| − | | + | |
| − | Самая распространенная в настоящее время методология проектирования сложных систем — '''DDD''' (Domain Driven Design) — предлагает строить архитектуру на основе модели предметной области, формируя '''единый язык''' для всех участников проекта. В качестве основного средства построения моделей используют ООП (объектно-ориентированное программирование) — в том числе, благодаря объектной парадигме основных языков реализации (C#, Java).
| + | |
| − | | + | |
| − | Однако объектная модель, выраженная в диаграмме классов, не всегда является хорошим единым языком. Например, потому, что в самой предметной области важны поведенческие или другие аспекты, эффективно отражаемые другими видами диаграмм.
| + | |
| − | | + | |
| − | В таких случаях рационально использовать необъектную модель, даже если ее реализация будет осуществляться с помощью объектных языков и сред. Сочетание необъектной модели с объектной реализацией будет показано на двух примерах.
| + | |
| − | | + | |
| − | Первый пример — известный шаблон State Entity, который логичнее описывать диаграммой состояний, а не диаграммой классов. Второй, более сложный пример — представление учета, которому методологи не уделили должного внимания и для которого мы придумали свой способ — диаграммы учета.
| + | |
| − | | + | |
| − | Для успешного использования необъектной модели необходимо типовое отображение ее примитивов проектирования в реализацию на объектных языках, которое было найдено в обоих случаях. Это делает модель языком общения заказчика и разработчика, исключая необходимость перевода на язык объектной реализации.
| + | |
| − | | + | |
| − | Таким образом, необъектная модель и диаграммы, в которых она находит отражение, не являются иллюстративными схемами для заказчика и пользователя, а играют роль единого языка для всех участников проекта.
| + | |
| − | | + | |
| − | == Краткое изложение ==
| + | |
| − | | + | |
| − | Domain Driven Design является mainstream-методологией проектирования сложных систем. Он предлагает строить архитектуру на основе модели предметной области, формируя '''единый язык''' для всех участников проекта — от экспертов и пользователей заказчика до разработчиков и тестеров. А в качестве основного средства построения моделей предлагается широко известный ООП. И не только в силу хорошо зарекомендовавшей себя и проработанной методологии, но и потому, что построенные модели соответствуют парадигме современных объектных языков программирования, таких как C# и Java.
| + | |
| − | | + | |
| − | Однако, существуют области (или фрагменты областей), в которых объектная модель, выраженная в диаграмме классов, не может выполнять роль единого языка, и потому не может являться хорошим способом проектирования. Причина может быть в том, что в самой предметной области преобладают поведенческие, а не структурные аспекты, выражаемые другими диаграммами. Или в том, что в рамках предметной области может существовать общепринятый язык для хорошего описания со своими диаграммами. Тогда их логичнее использовать, даже если реализация будет выполняться на объектных языках программирования и в объектной модели. Но бывает и так, что объектная модель не слишком подходит для решения конкретной задачи. Хорошо известным примером такой области может быть система показателей с различными разрезами, для работы с которой обычно применяют многомерные модели данных. Во всех этих случаях Эрик Эванс в классической книге по DDD рекомендует искать и использовать другие подходы.
| + | |
| − | | + | |
| − | Отметим, что реализация даже не объектной модели, как правило, выполняется с помощью объектных языков и сред, поскольку именно они представляются наиболее современной технологической платформой. Сочетание не-объектной модели с объектной реализацией — достаточно интересно. Оно будет рассмотрено на двух примерах.
| + | |
| − | | + | |
| − | Первый — для давно известного шаблона State Entity, который правильно описывать через диаграмму состояний, а вовсе не диаграмму классов. Именно диаграмма состояний будет служить тем единым языком общения. При этом техническая реализация может быть различной, например, Эванс приводит три возможных варианта. И их можно выбирать в зависимости от особенностей конкретного проекта, используя, однако, единую схему в каждом проекте.
| + | |
| − | | + | |
| − | Второй, более сложный пример, касается представления учета. Это профильная деятельность нашей компании, обойденная вниманием методологов. И для нее мы придумали свой способ — диаграммы учета. При этом, как и в случае State Entity, техническая реализация может быть различна.
| + | |
| − | | + | |
| − | Общий подход, примененный в обоих случаях, при реализации проекта состоит в выборе способа, с помощью которого примитивы проектирования отображаются в объектную реализацию. И после этого выбора соответствующие специализированные диаграммы могут служить единым языком проектирования. IT-специалисты знают способ отображения в объектную реализацию и потому им не требуется каждый раз осуществлять перевод.
| + | |
| − | | + | |
| − | По опыту, использование необъектных моделей проектирования при реализации на объектных языках является не слишком понятным для разработчиков. Они склонны рассматривать эти схемы как иллюстративные, для объяснения заказчику, а вовсе не как составляющие единого языка, на котором строится модель. Надеемся, что доклад поможет достичь понимания этого различия.
| + | |
| − | | + | |
| − | == Об авторе ==
| + | |
| − | | + | |
| − | Я – соучредитель и главный архитектор компании CUSTIS, в которой работает со дня основания (1996). Образование, можно сказать, классическое - закончил с отличием Факультет управления и прикладной математики Московского физико-технического института.
| + | |
| − | | + | |
| − | Я верю, что автоматизация - дает новые возможности развития. Поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Создание архитектуры реальных систем, особенно в заказной разработке - интереснейший процесс поиск баланса между общими архитектурными подходами и реализацией специфических требований конкретного проекта. Я участвовал в разработке множества проектов и нескольких фреймворков компании.
| + | |
| − | | + | |
| − | Я верю в эффективность командной работы, эффективность профессиональных сообществ, и категорически не согласен рассматривать людей как ресурсы. Это современный тренд - гибкие методологии разработки. Это относится и к проектированию архитектуры, вопреки достаточно распространенному мнению о примате в этой области единоличного креативного творца - по моему опыту, лучшие архитектуры создавались совместно сильными архитекторами, хотя договариваться было и не просто. Свои взгляды я пропагандирую как в профессиональных сообществах, таких как AgileRussia, так и участвуя в развитии процессов внутри компании.
| + | |
| − | | + | |
| − | == Ссылки ==
| + | |
| − | | + | |
| − | Шаблоны:
| + | |
| − | * Фаулер http://martinfowler.com/eaaDev/AccountingNarrative.html
| + | |
| − | * State Entity http://blogs.sun.com/jkumaran/entry/state_design_pattern_using_java
| + | |
| − | | + | |
| − | {{replicate-from-custiswiki-to-lib}}
| + | |
