Здравствуйте!

Есть обычная задача. БД, Сервер, Клиент (клиент толстый, Swing-овый и некий набор сторонних систем для интеграции.

И конечно же по всем рекомендациям различных архитекторов было оно реализовано так:

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

Пример:
— На сервере есть класс доменной модели "User". У него есть куча полей типа имя, логин, пароль. адрес, настройки и т.п.
— На клиенте есть форма, которая позволяет изменить, например, личную инфу по юзеру (имя, логин и пароль). Для этого на клиенте создается объект, который содержит эти 3 поля. Назовем его ClientUser. По сути, умным словом он называется DTO.
— Клиент запрашивает данные типа "дай-ка мне юзера" и отдает объект ClientUser. Сервак достает нужный объект модели и потом незатейливым конвертером конвертит его в ClientUser и отдает клиенту.
— Клиент получает объект и оборачивает его в другой (создает декоратор). Декоратор этот нужен для того, чтобы на сервак не попадали клиентские либы, связанные с валидацией и прочей мутью. Просто используемая либа имеет плохое свойство вклиниваться в объект и заставлять его делать extends SomeSuperObject чтоб она могла работать.
Далее всё это интегрируется в работу клиентского приложения.

Так вот, что меня интересует. Почему бы в этом случае вообще не отказаться от всяких DTO и декораторов? ИМХО, они похожи на большую свалку, которая только и делает что таскает данные от клиента серверу, захламляет проект и вынуждает писать кучу конвертеров, что приводит к появлению ошибок. Так как каждый объект клиента является срезом модели сервера, почему бы просто не юзать одну модель как на сервере, так и на клиенте?

Что соб-сно не нравится в распределенной модели:

1. Придется допилить конвертер так, чтобы он частично инициализировал объекты доменной модели. Только те данные, которые нужно. С тем конвертером что щас это будет выглядеть как конвертация объекта User в объект User, но только с определенными правилами среза, т.е. я буду указывать какие поля брать, а какие нет.

2. Появится некоторая недосказанность по поводу того, какие поля у User можно юзать "здесь", а какие "там". Недосказанность эта будет указываться в конвертере что тоже не есть гуд как мне кажется.

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

Хочется преобразовать это всё к виду "одна распределенная модель данных как для клиента, так и для сервера" и поэтому и интересуюсь у вас что вы думаете по этому поводу и какие могут быть ещё подводные камни при таком подходе. Напрашивается какое-то подобие Hibernate, только для работы с сервером.