Распознавание приложения «формы поверх данных» и, скажем, приложения DDD

Question

Я часто вижу заявления типа «Приложение x не имеет достаточно сложного домена, чтобы оправдать издержки многоуровневой архитектуры. Оно лучше подходит для подхода к формам, а не к данным». Мне интересно, каковы характеристики домена, который заставил бы пойти с определенным подходом. То есть, как вы можете определить, когда нужно делать что-то простое, например, формы над данными, или когда вам нужно создать несколько уровней, домен, DTO и т. Д.

Answer 1

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

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

Вы можете попробовать задать этот вопрос на доске объявлений DDD

Answer 2

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

Я думаю, что возможно иметь шаблоны и практики, которые лежат где-то посередине; где вы пишете программное обеспечение, но в большинстве случаев подходит то, что вам и так удобно. (Я думаю, что ключевое слово - это сильная связь с «узорами».)

Хорошим конкретным примером является недавно популярная концептуальная структура MVC (и его родство). К ним можно относиться довольно обобщенно; и вы можете или не можете платить за инструменты на основе вашей платформы, контекста и / или личных предпочтений. Но я думаю, что не так много ситуаций, когда MVC и т. Д. Были бы не в восторге или не в восторге (но один из двух вариантов, предложенных в этом вопросе, был бы решительно лучше).

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