EagerReadDerivation: баланс выгод с затратами

Question

Я изучаю доменно-управляемый дизайн и распределенный DDD для будущего приложения Silverlight, над которым я буду работать. Кажется, что шаблон EagerReadDerivation улучшит масштабируемость приложения, но за счет увеличения сложности.

В приложении потенциально могут быть тысячи пользователей, загружающих большие текстовые файлы (более 100 000 строк), которые необходимо будет обрабатывать несколькими службами. Нам также потребуется поддержка сценариев «что, если» (а-ля ParallelModel). Я считаю, что подход, основанный на моделях, поможет нам управлять сложностью, поэтому я бы хотел как можно больше не использовать логику в базе данных.

У меня вопрос к разработчикам, которые попробовали шаблон EagerReadDerivation: он окупился за вас и стоило ли это дополнительной сложности в вашем приложении?

Answer 1

Чтобы оценить преимущества, вы должны учитывать соотношение загрузки / запроса. Если у вас больше запросов, чем загрузок, вам обязательно следует применить обработку при загрузке.

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

В любом случае, не включайте логику в базу данных, как вы планировали.