Smart UI VS. Layered Architecture

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

В литературе встречаются определения подобного подхода:

• Интеллектуальный интерфейс пользователя (Smart UI) в «Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем» Эрика Эванса
• Сценарий транзакции (Transaction Script) в «Шаблоны корпоративных приложений» (Patterns of Enterprise Application Architecture) Мартина Фаулера

Проще говоря, если у вас «скрипты в формочках» - это оно и есть. :)

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

К сожалению, нужно признать, что данный подход имеет  определенные преимущества.

Преимущества:

• Высокая производительность труда и мгновенный результат в простых приложениях. Возможность быстро реагировать на потребности рынка.
• «Возьмем на работу даже студентов.»  Разработчикам практически не требуется дополнительное обучение, чтобы приступить к работе. 
• Даже недостатки в анализе технического задания можно преодолеть, выпустив прототип для пользователей, и затем быстро внести нужные изменения.
• Функции и операции отделены друг от другой, так чтобы можно более-менее точно спланировать сроки готовности небольших модулей. Расширение системы за счет дополнительных простых функций выполняется легко.
• «Сейчас мы это все по-быстрому перепишем.»  При передаче приложения в другие руки новые разработчики смогут быстро переделать фрагменты кода, которых они не понимают, потому что эффект внесенных изменений должен локализоваться в каждом отдельном интерфейсе. 

Недостатки:

• Разработчики не чувствуют потребности в развитии, в результате работы получается код низкого качества. Системы с применением подобного подхода, как правило, характеризуются низкой стоимостью ошибки. В лучшем случае, разработчиками будет накоплен опыт в понимании предметной области.
• Развитие возможно только в сторону дополнительных простых приложений. Невозможно «изящно» реализовать сложные функции и сложное поведение системы.
• Невозможность перейти к другой методологии проектирования или фреймворку. «Хотите веб – придется переписать все заново» .
• Интеграция между различными приложениями возможна  разве что через базу данных.
• Отсутствует переносимость функциональных модулей и абстракция прикладных моделей. Правила прикладной модели приходится дублировать в каждой операции, связанной с ними.

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

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

Написано под впечатлением от просмотра исходного кода коллег, чтения великолепной книги Эрика Эванса, DDD (big blue book) и посещения самой крутой .NET конференции этой осени – NETWork,  о ней в следующий раз.