DDD и клиент / серверные приложения

Question

Мне было интересно, если кто-нибудь из вас успешно внедрил DDD в приложении клиент / сервер и хотел бы поделиться некоторыми впечатлениями.

В настоящее время мы работаем над интеллектуальным клиентом во Flex и бэкэндом в Java. На сервере у нас есть сервисный уровень, предоставляемый клиенту, который предлагает CRUD-операции среди некоторых других сервисных методов. Я понимаю, что в DDD эти сервисы должны быть репозиториями, а сервисы должны использоваться для обработки сценариев использования, которые не вписываются в репозиторий. Прямо сейчас мы имитируем эти сервисы на клиенте за интерфейсом и внедряем реализации (Webservices, RMI и т. Д.) Через контейнер IoC.

Поэтому возникает несколько вопросов:

• если сервер предоставляет репозитории клиенту или нам нужен какой-то фасад (который способен, например, обеспечивать безопасность)
• должен ли клиент реализовывать репозитории (и DDD в целом?), Зная, что в клиенте большая часть логики связана с представлением, а реальная бизнес-логика живет на сервере. Все взаимодействие с сервером происходит асинхронно, и у нас есть однопоточная модель программирования на клиенте.
• как насчет отображения клиента на объекты сервера и наоборот? Мы попробовали DTO, но вернулись к тому, чтобы показать состояние наших объектов и отобразить их непосредственно. Я знаю, что это считается плохой практикой, но это экономит нам невероятное количество времени)

В целом, я думаю, что новое поколение приложений приходит с ростом Flex, Silverlight, JavaFX, и мне интересно, как DDD вписывается в это.

Answer 1

1. Я бы не выставлял репозитории напрямую клиенту. Первая большая проблема, о которой вы упомянули, - это безопасность: вы не можете доверять клиенту, поэтому вы не можете предоставить свой API доступа к данным потенциально враждебным клиентам.
2. Оберните свои репозитории службами на сервере и создайте тонкий клиентский слой на клиенте, который обрабатывает удаленное взаимодействие.
3. Разоблачение ваших сущностей не обязательно является плохой практикой, просто становится проблематичным, когда вы начинаете учитывать такие вещи, как отложенная загрузка, отправка данных по проводам, которые не нужны клиенту и т. Д. Если вы пишете класс DTO, который оборачивает одну или несколько сущностей и делегирует вызовы get / set, вы можете довольно быстро создать слой DTO, особенно используя генерацию кода, доступную в большинстве IDE.

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

1. Клиент использует что-то вроде MVC, MVP или MVVM для представления пользовательского интерфейса. Слой модели в конечном итоге вызывает ...

2. Что я мог бы назвать «Интеграционный слой». Это контракт услуг и объектов данных, которые существуют как на клиенте, так и на сервере, что позволяет им координировать свои действия. Обычно дизайн пользовательского интерфейса управляет этим уровнем, так что (A) ему передаются только те данные, которые нужны клиенту, и (B) доступ к данным может быть грубым, т. Е. «Сделать один вызов метода для всех состояний, необходимых для этого набора UI.

3. Сервер использует все, что хочет, для обработки бизнес-логики и доступа к данным. Это может быть DDD или что-то более старое, например, слой данных, созданный с использованием хранимых процедур в БД и множества объектов ResultSet или DataTable.

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

Единственное большое преимущество, которое Silverlight / WPF и JavaFX имеют по сравнению с Flex +, - это то, что вы можете использовать много логики в первых двух, потому что у вас одна и та же виртуальная машина на обеих сторонах приложения. Flex - это лучшая технология пользовательского интерфейса, но в нем отсутствует серверный компонент, где код можно было бы совместно использовать и более эффективно использовать.