Где logging должен идти в архитектуре лука с DDD

Я разрабатываю консольное приложение, используя архитектуру лука и дизайн, ориентированный на домен. У меня есть два домена, где мне нужно реализовать ведение журнала, я смутил, где я могу разместить компонент регистрации. Могу ли я разместить это в соответствующей инфраструктуре двух доменов? Или В общем ядре, на которое можно ссылаться в обоих доменах? Если мне нужно разместить его в общем ядре, какова структура, над которой я должен следовать? Я имею в виду как ядро, инфраструктуру.Где logging должен идти в архитектуре лука с DDD

источник

2014-12-26 Mahesh kumar Chiliveri

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

Вам необходимо создать библиотеку и реализовать свои классы ведения журнала, что-то вроде «MyProject.CrossCutting.Logging». И используйте аспектно-ориентированные подходы к регистрации событий с использованием этой библиотеки.

Typical Onion Architecture

источник

2014-12-27 18:29:27

Это звучит правильно, но это обычно означает, что есть один централизованный журнал, но что, если вы хотите сохранить события для агрегатов - они, вероятно, будут иметь одну и ту же структуру, но они должны быть инкапсулированы (доступны только через общий корень) , так что, если у меня есть события для каждого агрегата - например SalesEvent, CustomerEvent. Затем, согласно DDD, ответственность за обработку этих событий должна быть ответственной за агрегирование root, не так ли? Или, может быть, это все равно означает, что регистратор находится в 'infrasture', а агрегированный root вызывает его« сохранить мои события », но как репозиторий разрешит, где хранить? – Prokurors

Если вы следуете DDD и лук архитектуры, это не имеет значения, сколько доменов у вас есть. При необходимости каждый домен может реализовать свою собственную версию Logger. Скорее всего, вы создадите интерфейс ведения журнала и, возможно, статическую реализацию, которая будет храниться в общем слое, который может быть вызван любым из слоев, которые ему нужны. В изображении, которое было ранее предоставлено, оно будет храниться в перекрестном слое. Как уже упоминалось ранее, Logging - это проблема всех слоев.

источник

2014-12-30 22:39:03

Согласно предыдущему предложению, мы создали интерфейс для регистратора в основной и конкретной реализации в общем ядре, мы вставляем эту конкретную реализацию в основное ядро из основной программы, которая использует сервисы ядра. я иду в правильном направлении? –

@MaheshkumarCh Регистрация не касается домена. Он не должен быть ни в одной модели домена, будь то совместное ядро или автономный домен. – guillaume31

Затем, куда нужно идти? Я использую архитектуру лука. Я использую ведение журнала в службах для регистрации всех операций. –

Ведение журнала является сквозным на всех ваших приложениях. Это должно быть частью вашей структуры. Все слои всех ваших проектов приложений могут зависеть от вашей структуры, так же, как они зависят от .NET Framework, Spring и т. Д. Если ваша структура должна иметь абстракции для сквозных проблем, на которые вы легко можете положиться, а затем реализация должна быть указана в корне композиции приложения, находящегося в инфраструктуре.

источник

2015-03-10 08:30:11 Daniel

Где logging должен идти в архитектуре лука с DDD

ответ

Смежные вопросы