나는 양파 아키텍처와 도메인 기반 디자인을 사용하여 콘솔 응용 프로그램을 개발 중입니다. 두 개의 도메인이있어 로깅을 구현해야하는데 어디에서 로깅 구성 요소를 배치 할 수 있는지 혼란 스럽습니다. 이를 두 도메인의 각 인프라에 배치 할 수 있습니까? 또는 두 도메인에서 모두 참조 할 수있는 공유 커널에서? 내가 따라야하는 구조가 공유 커널에 있어야한다면 코어 인프라와 같은 뜻입니다.DDD가있는 양파 아키텍처에서 로깅을 수행해야하는 곳
로깅은 교차 관심사입니다. 애스펙트 지향 프로그래밍은 측면에 대한 교차 관심사를 캡슐화하는 것을 목표로합니다. 이를 통해 교차 절단 문제를 다루는 코드를 깨끗하게 격리하고 재사용 할 수 있습니다.
"MyProject.CrossCutting.Logging"과 같은 라이브러리를 만들고 로깅 클래스를 구현해야하며, aspect 지향 접근법을 사용하여이 라이브러리를 사용하여 이벤트를 기록해야합니다.
당신이 DDD와 양파 아키텍처를 다음과 같은 경우, 당신이 얼마나 많은 도메인 문제가되지 않습니다. 필요한 경우 각 도메인에서 자체 버전의 로거를 구현할 수 있습니다. Logging Interface와 Common Layer에 유지 될 수있는 정적 구현을 생성하여 필요로하는 레이어로 호출 할 수 있습니다. 이전에 공유 된 이미지에서는 크로스 커팅 레이어에 유지됩니다. 앞서 언급했듯이 로깅은 모든 계층의 관심사입니다.
이전 제안에 따라, 우리가 한 일은 로거에 대한 인터페이스를 공유 커널에서 구현하고 구체적인 구현은 코어의 서비스를 사용하는 주 프로그램에서 코어에이 구체적인 구현을 주입하는 것입니다. 나는 올바른 방향으로 가고 있니? –
@MaheshkumarCh 로깅은 도메인 문제가 아닙니다. 공유 커널이든 독립형 도메인이든 관계없이 도메인 모델에 있어서는 안됩니다. – guillaume31
그런 다음 로깅은 어디로 가야합니까? 나는 양파 건축술을 사용하고 있습니다. 모든 작업을 기록하는 서비스 로깅을 사용하고 있습니다. –
로깅은 모든 응용 프로그램에서 크로스 커팅됩니다. 그것은 당신의 틀의 일부분이어야합니다. 모든 응용 프로그램 프로젝트의 모든 계층은 .Net Framework, Spring 등에 의존하는 것과 같은 방식으로 프레임 워크에 종속 될 수 있습니다. 프레임 워크에 쉽게 의존 할 수있는 교차 절단 문제에 대한 추상화가 있어야하는 경우, 구현은 인프라에있는 응용 프로그램의 구성 루트에서 참조되어야합니다.
소리가 맞지만 일반적으로 하나의 중앙 집중식 로그가 있음을 의미하지만 집계에 대한 이벤트를 저장하려는 경우 - 구조는 동일하지만 캡슐화해야합니다 (집계 루트를 통해서만 액세스 가능) 그래서 SalesEvent, CustomerEvent와 같은 각 집계별로 이벤트가 있다면 어떻게 될까요? 그런 다음 DDD에 따르면 이러한 이벤트를 처리하는 것은 집계 루트의 책임이어야합니다. 그렇지 않습니까? 아니면 여전히 로거가 '인프라 스트럭처'에 있다는 것을 의미 할 수도 있고 루트를 집계하는 것은 "내 이벤트 저장"이라고 할 수 있습니다.하지만 로거가 저장할 위치를 어떻게 결정할 수 있습니까? – Prokurors