Необъектные модели предметной области. Опыт CUSTIS (Максим Цепков, ADD-2011)

Короткая ссылка: Non object model

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

Доклад на конференции 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 года). С отличием окончил факультет управления и прикладной математики Московского физико-технического института.

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

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

Примечания и отзывы

• страничка доклада на сайте конференции

Шаблоны:

• Фаулер http://martinfowler.com/eaaDev/AccountingNarrative.html
• State Entity http://blogs.sun.com/jkumaran/entry/state_design_pattern_using_java

---

Максим Цепков показал UML-like картинки и рассказал, чем можно заменить объектную модель при проектировании. Навороченно :). ©

Необычный подход, поэтому, думаю, стоит посмотреть как альтернативу объектным моделям. …

Доклад интересный, но материала было, как мне кажется, больше чем времени, поэтому в конце пришлось бежать “галопом по Европе”.

©

⚓

Кажется, третий доклад Максима из серии про необъектные (не ООП-ориентированные) способы осмысления предметной области. Мне понравилось, так же как доклад на Agile Days.

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

Application Developer Days 2: Отчет Кудрявцева В.Б/Необъектные модели предметной области

---

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