Интерфейс ведения журнала на уровне домена

#c# #logging #domain-driven-design #onion-architecture

#c# #ведение журнала #дизайн, управляемый доменом #onion-архитектура

Вопрос:

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

 public interface ILogger {
    void Log(LogEntry entry);
}

Теперь мой вопрос — к чему относится этот интерфейс? Конечно, ведение журнала может быть проблемой инфраструктуры (и немного межуровневой проблемой), но если я помещу его на уровень инфраструктуры, мои доменные службы не получат к нему доступа. Если я помещаю его на уровень домена, я ввожу концепцию входа в свой домен, что кажется неудобным.

Я уже использую определенные концепции из CQRS amp; EventSourcing в своем приложении, однако создание события для like все, что происходит с данными внутри доменной службы, кажется излишним (особенно если данные попадают в состояние, которое не возвращается доменной службой до тех пор, пока не будут выполнены дальнейшие преобразования.)

Ответ №1:

Здесь есть несколько вариантов.

Используйте декораторы. Вы говорите, что уже используете CQRS, поэтому добавьте декораторы к командам / запросам, которые вы хотите зарегистрировать. Недостатком является то, что вы можете входить в систему только до и после выполнения команды / запроса, а не во время выполнения. И я не уверен, что таким образом будет легко регистрировать ваши события.
Используйте свой интерфейс. Если вы выберете этот путь, то действительно ваш ILogger интерфейс должен быть на уровне домена, потому что для домена потребуется компонент, который реализует ваши требования к регистратору, поэтому именно уровень домена определяет этот интерфейс. Реализация этого должна быть в другом месте, и на уровне инфраструктуры, по-моему, звучит нормально.

1. оба пункта являются решениями, но я бы, вероятно, выбрал первый, если бы мне пришлось выбирать. Большинство, если не все, бизнес-домены не связаны с ведением журнала.

Ответ №2:

[…] мои доменные службы не получают к нему доступа

Почему бы и нет? ILogger должен находиться на уровне инфраструктуры, но кто сказал, что уровень домена не имеет доступа к элементам инфраструктуры?

Насколько я знаю, инфраструктура — это несвязанный код, не относящийся к конкретному домену, который решает общие проблемы, такие как ввод-вывод, сеть, доступ к базе данных и так далее. А ведение журнала — это проблема инфраструктуры.

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

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