Разработка через домен и богатый графический интерфейс

Question

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

Обычно концепция DDD означает «99% логики в домене и 1% логики в GUI»; а логика в GUI - это только проверка. Такой подход хорошо работает, когда у вас есть простые формы, где пользователи могут что-то ввести, а затем нажать «Сохранить», чтобы отправить данные на сервер или что-то в этом роде.

Одной из основных особенностей существующего приложения является его быстрота. Работа на POS означает, что продавец делает все быстро. Бизнес-логика, которой должен следовать POS, очень сложна. Грубо говоря, каждый раз, когда пользователь меняет цену, налоги, скидки и т. Д., Меняются цены, скидки, налоги и т. Д .; так что это своего рода домен, который находится на клиенте.

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

Есть ли идеи о том, как сохранить чистоту DDD и в то же время сделать систему быстрой?

Спасибо!

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

Answer 1

Одна концепция заключается в том, чтобы иметь на клиенте быструю проверку , которая не пытается быть точной на 100%, но может обнаружить, возможно, 95% неверных входных данных.

В вашем примере этобыстрая проверка может проверять такие вещи, как:

• скидка больше 0 и <цена </li>
• налог где-то между 0 и 25%

Ввод отправляетсяна сервер для полной проверки, только если он прошел быстрый клиентский тест.

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

Только 5% неверных входных данных приведут к тому, что ошибка будет отображаться первой после сервераконтакт.Что, вероятно, нормально, если пользователь обычно не предоставляет неверные данные - что частично зависит от того, насколько хорошо спроектирован пользовательский интерфейс.

Критическое - быстрая проверка никогда не должна говорить о том, что действительные данные недействительны.

Answer 2

вероятно, вы можете попробовать использовать отдельные «два приложения» (два модуля) каждое, как в философии DDD: - обслуживание клиентов в POS - услуги магазина в «сервере» ... оба модуля должны быть интегрированы... например, через сеть ...

Answer 3

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

Лично мне нравится занимать позицию по умолчанию, начиная с «чистого» и допуская только компромиссы с шаблоном DDD, когда тестирование производительности в реальных условиях доказывает, что это необходимо.

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