Кэширует репозиторий, домен или приложение?

Я пытаюсь выяснить, какой слой должен отвечать за кеширование (вставить/удалить) в проекте Domain Driven Design. Целью является повышение производительности веб-приложения путем кэширования любых объектов, которые извлекаются из репозитория.

Мое решение разделяется следующим образом:

MyApp.Infrastracture
MyApp.Repositories
MyApp.Domain
MyApp.WebApplication

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

Также кэширование не является концепцией домена первого класса, поэтому не имеет естественного соответствия в уровне домена.

Что делать?

Ответ 1

Это относится ко всему вышесказанному.

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

Ответ 2

Вы отметили

Целью является улучшение производительности веб-приложения путем кэширования любые объекты, которые извлекаются из репозитория.

Поэтому я думаю, что вы должны реализовать его прозрачно в своем репозитории. Хранилище предназначено, чтобы скрыть детали сохранения из домена, и если вы хотите кэшировать большие объекты для производительности, тогда домен не должен быть более мудрее. Ваш репозиторий должен будет получить немного умнее, потенциально отслеживая несколько копий того же объекта, что и объекты запросов параллельных потоков, и одновременно их мутировать. Или - если возможно - сериализуйте доступ к отдельным корневым элементам, поскольку они представляют границы транзакций.

Как отметил @Oded, кэширование действительно может произойти в любом месте, и вы, вероятно, обнаружите, что реализуете его во многих местах, если производительность является проблемой, и каждое место может сделать это по-другому. Например, вы можете кэшировать результат определенных запросов в своем домене или кэшировать все ответы HTML.

Координация перекрестного слоя возникает из-за того, что кэши могут быть довольно непроницаемой абстракцией. Если ваши объекты домена кэшируются, когда они должны быть закрыты? Что делать, если один поток использует кешированный объект, а другой нет? Что делать, если вы кэшируете результаты запроса, но с тех пор изменились базовые объекты? Когда делать недействительными и как недействительными являются трудными вопросами, как с точки зрения инфраструктуры, так и с точки зрения бизнеса. Простые запросы не всегда плохие.

Ответ 3

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

Например, пользователям вашего репозитория не должно заботиться о кэшировании элемента или нет.

Я бы сказал, что если кеширование является важным аспектом вашего решения, тогда оно должно быть ясным в Домене, однако вы, вероятно, обнаружите, что он фактически заканчивается как часть инфраструктуры и доставляется (тихо) через какой бы то ни было IoC, который вы используете.

Ответ 4

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