|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Необъектные модели предметной области. Опыт CUSTIS (Максим Цепков, ADD-2011)Материал из CustisWikiЭто снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. Короткая ссылка: Non object model Доклад на конференции Application Developers Days 29-30.04 Питер СодержаниеТезисы докладаСамая распространенная в настоящее время методология проектирования сложных систем — DDD (Domain Driven Design) — предлагает строить архитектуру на основе модели предметной области, формируя единый язык для всех участников проекта. В качестве основного средства построения моделей используют ООП (объектно-ориентированное программирование) — в том числе, благодаря объектной парадигме основных языков реализации (C#, Java). Однако объектная модель, выраженная в диаграмме классов, не всегда является хорошим единым языком. Например, потому, что в самой предметной области важны поведенческие или другие аспекты, эффективно отражаемые другими видами диаграмм. В таких случаях рационально использовать необъектную модель, даже если ее реализация будет осуществляться с помощью объектных языков и сред. Сочетание необъектной модели с объектной реализацией будет показано на двух примерах. Первый пример — известный шаблон State Entity, который логичнее описывать диаграммой состояний, а не диаграммой классов. Второй, более сложный пример — представление учета, которому методологи не уделили должного внимания и для которого мы придумали свой способ — диаграммы учета. Для успешного использования необъектной модели необходимо типовое отображение ее примитивов проектирования в реализацию на объектных языках, которое было найдено в обоих случаях. Это делает модель языком общения заказчика и разработчика, исключая необходимость перевода на язык объектной реализации. Таким образом, необъектная модель и диаграммы, в которых она находит отражение, не являются иллюстративными схемами для заказчика и пользователя, а играют роль единого языка для всех участников проекта. Презентация
Краткое изложениеDomain Driven Design является mainstream-методологией проектирования сложных систем. Он предлагает строить архитектуру на основе модели предметной области, формируя единый язык для всех участников проекта — от экспертов и пользователей заказчика до разработчиков и тестеров. А в качестве основного средства построения моделей предлагается широко известный ООП. И не только в силу хорошо зарекомендовавшей себя и проработанной методологии, но и потому, что построенные модели соответствуют парадигме современных объектных языков программирования, таких как C# и Java. Однако, существуют области (или фрагменты областей), в которых объектная модель, выраженная в диаграмме классов, не может выполнять роль единого языка, и потому не может являться хорошим способом проектирования. Причина может быть в том, что в самой предметной области преобладают поведенческие, а не структурные аспекты, выражаемые другими диаграммами. Или в том, что в рамках предметной области может существовать общепринятый язык для хорошего описания со своими диаграммами. Тогда их логичнее использовать, даже если реализация будет выполняться на объектных языках программирования и в объектной модели. Но бывает и так, что объектная модель не слишком подходит для решения конкретной задачи. Хорошо известным примером такой области может быть система показателей с различными разрезами, для работы с которой обычно применяют многомерные модели данных. Во всех этих случаях Эрик Эванс в классической книге по DDD рекомендует искать и использовать другие подходы. Отметим, что реализация даже не объектной модели, как правило, выполняется с помощью объектных языков и сред, поскольку именно они представляются наиболее современной технологической платформой. Сочетание не-объектной модели с объектной реализацией — достаточно интересно. Оно будет рассмотрено на двух примерах. Первый — для давно известного шаблона State Entity, который правильно описывать через диаграмму состояний, а вовсе не диаграмму классов. Именно диаграмма состояний будет служить тем единым языком общения. При этом техническая реализация может быть различной, например, Эванс приводит три возможных варианта. И их можно выбирать в зависимости от особенностей конкретного проекта, используя, однако, единую схему в каждом проекте. Второй, более сложный пример, касается представления учета. Это профильная деятельность нашей компании, обойденная вниманием методологов. И для нее мы придумали свой способ — диаграммы учета. При этом, как и в случае State Entity, техническая реализация может быть различна. Общий подход, примененный в обоих случаях, при реализации проекта состоит в выборе способа, с помощью которого примитивы проектирования отображаются в объектную реализацию. И после этого выбора соответствующие специализированные диаграммы могут служить единым языком проектирования. IT-специалисты знают способ отображения в объектную реализацию и потому им не требуется каждый раз осуществлять перевод. По опыту, использование необъектных моделей проектирования при реализации на объектных языках является не слишком понятным для разработчиков. Они склонны рассматривать эти схемы как иллюстративные, для объяснения заказчику, а вовсе не как составляющие единого языка, на котором строится модель. Надеемся, что доклад поможет достичь понимания этого различия. Видео
Видео в HD-качестве, смотрите в полноэкранном режиме. HTML-код включения <iframe src="http://player.vimeo.com/video/23899443?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/2a4-non-objective-domain-models-tsepkov.avs.avi Для этого доклада нужен подкаст (аудиозапись)?
Об авторе
Я — соучредитель и главный архитектор компании CUSTIS, в которой работаю со дня основания (1996). Образование, можно сказать, классическое — закончил с отличием Факультет управления и прикладной математики Московского физико-технического института. Я верю, что автоматизация — дает новые возможности развития. Поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Создание архитектуры реальных систем, особенно в заказной разработке — интереснейший процесс поиск баланса между общими архитектурными подходами и реализацией специфических требований конкретного проекта. Я участвовал в разработке множества проектов и нескольких фреймворков компании. Я верю в эффективность командной работы, эффективность профессиональных сообществ, и категорически не согласен рассматривать людей как ресурсы. Это современный тренд — гибкие методологии разработки. Это относится и к проектированию архитектуры, вопреки достаточно распространенному мнению о примате в этой области единоличного креативного творца — по моему опыту, лучшие архитектуры создавались совместно сильными архитекторами, хотя договариваться было и не просто. Свои взгляды я пропагандирую как в профессиональных сообществах, таких как AgileRussia, так и участвуя в развитии процессов внутри компании. Примечания и отзывыШаблоны:
Максим Цепков показал UML-like картинки и рассказал, чем можно заменить объектную модель при проектировании. Навороченно :). ©
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |