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

Question

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

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

Так возникают некоторые вопросы:

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

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

Answer 1

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

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

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

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

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

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

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