Я разрабатываю консольное приложение, используя луковую архитектуру и дизайн, управляемый доменом. У меня есть два домена, где мне нужно реализовать ведение журнала, я запутался, где я могу разместить компонент ведения журнала. Могу ли я разместить это в соответствующей инфраструктуре двух доменов? Или в общем ядре, на которое можно ссылаться в обоих доменах? Если мне нужно поместить его в общее ядро, какой структуре я должен следовать? Я имею в виду ядро, инфраструктуру.
Где должно вестись ведение журнала в луковой архитектуре с DDD
Ответы (3)
Ведение журнала является сквозной проблемой. Аспектно-ориентированное программирование направлено на то, чтобы инкапсулировать сквозные проблемы в аспекты. Это позволяет полностью изолировать и повторно использовать код, решающий сквозную проблему.
Вам нужно создать библиотеку и реализовать свои классы ведения журнала, что-то вроде «MyProject.CrossCutting.Logging». И использовать аспектно-ориентированные подходы для регистрации событий с использованием этой библиотеки.
person
Hadi Ahmadi
schedule
27.12.2014
Звучит правильно, но в целом это будет означать, что есть один централизованный журнал, но что, если вы хотите сохранять события для агрегатов - они, вероятно, будут иметь одинаковую структуру, но они должны быть инкапсулированы (доступны только через root агрегата), так что что? если у меня есть события для каждого агрегата - например, SalesEvent, CustomerEvent. Тогда, согласно DDD, за обработку этих событий должен нести ответственность Aggregate root, не так ли? Или, может быть, это по-прежнему будет означать, что регистратор находится в
infrasture, и совокупный корень вызывает его, чтобы сохранить мои события, но как регистратор решит, где хранить?
- person Prokurors; 08.10.2016
Журналы @Prokurors IMHO должны быть отправлены из приложения как можно скорее унифицированным способом для всего приложения, поскольку журналы используются для отладки, и если приложение неожиданно выйдет из строя до того, как журналы будут отправлены, они будут потеряны. Таким образом, наиболее целесообразно иметь один централизованный журнал для каждого приложения. Журналы могут быть децентрализованы позже, если это необходимо, на основе тегов обработчиком журналов, который работает вне приложения. События отличаются от журналов. События могут быть отправлены репозиторием только после того, как агрегат был успешно зафиксирован в базе данных, отбрасывая их, если ожидается сбой фиксации.
- person Ski; 30.10.2020
Ведение журнала является сквозным для всех ваших приложений. Это должно быть частью вашей структуры. Все уровни всех ваших проектов приложений могут зависеть от вашей среды точно так же, как они зависят от .Net Framework, Spring и т. д. Ваша среда должна иметь абстракции для сквозных задач, на которые вы можете легко положиться, и тогда реализация просто должна быть указана в корне композиции приложения, которое находится в инфраструктуре.
person
Daniel
schedule
10.03.2015
Если вы следуете DDD и луковой архитектуре, не имеет значения, сколько у вас доменов. Каждый домен может реализовать свою собственную версию регистратора, если это необходимо. Скорее всего, вы создадите интерфейс ведения журнала и, возможно, статическую реализацию, которая хранится на общем уровне и может быть вызвана любым из уровней, которые в ней нуждаются. В изображении, которое было опубликовано ранее, оно будет храниться на сквозном слое. Как упоминалось ранее, ведение журнала касается всех уровней.
person
Eddie
schedule
30.12.2014
В соответствии с предыдущим предложением мы создали интерфейс для регистратора в ядре и конкретную реализацию в общем ядре, мы внедряем эту конкретную реализацию в ядро из основной программы, которая использует службы ядра. я иду в правильном направлении?
- person Mahesh kumar Chiliveri; 31.12.2014
@MaheshkumarCh Ведение журнала не относится к домену. Его не должно быть ни в одной модели домена, будь то общее ядро или автономный домен.
- person guillaume31; 06.01.2015
Тогда куда должна идти регистрация? Я использую луковую архитектуру. Я использую регистрацию в службах для регистрации всех операций.
- person Mahesh kumar Chiliveri; 07.01.2015
Ведение журнала настраивается в пользовательском интерфейсе (консоль, ASP.NET Core и т. д.), а затем внедряется в инфраструктуру.
- person gimlichael; 25.09.2019
Итак, будучи чисто инфраструктурным сервисом, будут ли интерфейс и реализация Logger определяться на уровне инфраструктуры?
- person Mr. Mars; 03.04.2020
