Domain, Context, Integration. Как увидеть динамику в статике кода.

Доклад с конференции, вы не поверите, «Java сегодня и завтра. Просто о сложном».

Большинство из нас, если не все, для разработки больших приложений, для бизнес-приложений по большому счету, используют Domain Driven Design подход описанные Эриком Эвансом в 2004 году. Это способ проектирования, который фокусируется прежде всего на предметной области, на объектах реального мира, их поведении и взаимодействии, то есть фокусируется на модели и бизнес-логике. Однако реальные связи в таком коде чаще всего строятся и можно увидеть только в режиме run-time. Данный доклад ставит своей целью не столько показать конкретный код, сколько направить мысль разработчика на новую тему.

 

Hard’n’Heavy!

DCI презентация для TechEd2012

Всем привет!

Как я и обещал первые драфты презентации доступны в SkyDrive по этой ссылке. https://skydrive.live.com/redir?resid=91D2A6BED92B69C5!567&authkey=!AL5e-t6Tc-M84R8 В презентации к слайдам есть комментарии. Это если их не видно сразу.

Презентация будет постоянно обновляться до тех пор, пока я ее не расскажу или же мне не откажут в принятии заявки =) Надеюсь, что последнее не произойдет.

Комментарии, предложения, дополнения и прочее приветствуются.

 

UPD: Статью не приняли на TechEd, так как судя по расписанию треков там только нужны WinPhone8, Win8, Server 2012 доклады, зато предложили сделать подкаст для TechDays. А так же есть предварительная договоренность выступить с этой презентацией на JavaConf от Luxoft в середине декабря.

Так что вроде бы все не зря )

Domain, Context & Integration (DCI)

Относительно недавно на хабрахабре попалась статья Data Context Interaction (DCI) — эволюция объектно-ориентированной парадигмы, которая меня весьма заинтересовала описанным подходом, но примеры в ней были тупо скопированы с оригинальных публикаций 3х годичной давности или около того. Вообще все статьи по теме оперируют одним и тем же примером, который, на мой взгляд, не до конца раскрывает тему и все плюсы использования DCI. Но это общая проблема интернетов, даже уже говорить про это не хочется.

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

Для начала все же стоит привести немного теории, для тех, кому лень читать статью с хабра.

Проблема

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

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

Рассмотрим второй возможный сценарий работы с теми же объектами:

Мы видим совсем другой сценарий использования, другая системная операция, использующая ту же самую группу объектов. Но модель взаимодействия объектов и сообщения уже другие.

Выше были представлены две системные операции выраженные в Use Case 1 и Use Case 2. Как мы их отображаем в коде? В идеальном случае, я бы хотел иметь возможность открыть один файл и понять модель взаимодействия объектов в сценарии использования, над которым я работаю. Если я работаю над Use Case 1, я ничего не хочу знать про Use Case 2. Вот что я считаю успешным отображением сценариев использования в коде.

На данный момент в гипотетическом коде, по которому построены UseCase может быть такое распределение методов.

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

Подробнее