В каком слое сбор метрик считается подходящим для дизайна, управляемого доменом?

Question

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

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

Answer 1

Решение будет меняться в зависимости от структуры и технологий, которые вы используете для его реализации, но позвольте мне привести некоторые общие рекомендации, которые широко применяются:

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

Когда показатели столь же важны, как и ваш домен, вам следует задуматься о том, чтобы рассматривать их как отдельные объекты.Они должны быть разработаны в отдельном контексте.Необходимые показатели и аналитика часто отличаются от традиционных потребностей CRUD, и здесь имеет смысл отдельный «ограниченный контекст».

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