내 MVC 응용 프로그램에 대한 사용자 정의 필터 인 [LogAttribute]을 만들었습니다. 액션 메소드는 이것으로 장식되어 있으며 어떤 유형의 제공자 (ILoggerProvider)에 전달할 LogEntry 객체를 생성 할 책임이 있습니다.로깅 로직은 DDD 솔루션 내에 어디에 있어야합니까?
제 질문은 어디서 ILoggerProvider이되어야하고 구현이 있습니까 (DI 기술을 사용하고 싶습니다)? 그들은 도메인 모델, UI 프로젝트 또는 별도의 클래스에 있어야합니까?
로깅은 UI와 아무 관련이 없으므로 이것은 분명히 잘못된 장소입니다. 내 의견으로는 도메인 모델이 데이터 표현을위한 것입니다. 그래서 나는 별도의 수업이나 별도의 프로젝트에서 그것을 할 것입니다.
로깅 서비스를위한 별도의 프로젝트가있는 MVC 응용 프로그램이 있습니다. 내 구조에서는 파일에 직접 기록하고 다른 모든 서비스에서 직접 사용하기 때문에 최하위 계층 (데이터 액세스)에 있습니다. 또한 MEF 프레임 워크를 사용하여 DI를 사용합니다.
이것은 잠시 동안 저에게 잘 돌아 왔고 그 이후로 변경하고 싶지 않았습니다. 나는 다른 해결책을 가지고 있었는데, 나는 잠시 후에 건너 뛰었습니다. 왜냐하면 그들은 현재의 솔루션으로 사용하기에는 우아하지 않았기 때문입니다.
귀하의 결정에 도움이되는 희망.
저는 일반적으로 ILoggingProvider가 몇 가지 이유 때문에 도메인 모델 내에 있어야한다고 주장했습니다. 물류 및 온전한 관점에서 볼 때 도메인 클래스는 아마도 로거를 참조해야 할 것입니다. DDD 관점에서 볼 때, 우리가 살고있는 SOX 세계를 고려할 때 로깅은 규정 준수를위한 핵심 도메인 기능이라고 주장 할 수 있습니다.
이제 구현은 인프라 프로젝트에서 확실히 끝날 수 있습니다. 모든 것을 포함하여 모델을 복잡하게 만들 필요가 없습니다. 소프트웨어의 주요 기능은 로깅 또는 감사 않는 한
은, 그것은 인프라 LoggingService해야합니다.
로깅 구현이 도메인 객체와 밀접하게 결합되어 있지 않으면 (나는 그렇지 않길 바랍니다!) 완전히 분리 된 어셈블리를 제안합니다.
나는 이것이 최상의 대답으로 표시된 대답보다 더 좋은 생각이라고 생각한다. –
동의했다. 이것은 더 나은 대답이다. – Josh
규제 기관이 귀하의 유비쿼터스 언어 (Ubiquitous Language, UL)에 제약을 가하고 있기 때문에 이는 의미가 있습니다. 특히, "당신과 그 사건을 기록하십시오"라는 규제는 당신의 모델에 상응하는 실체를 가지고 있습니다. 규정은 도메인의 일부가 될 수 있으며 UL에 따라 모델에 로깅 인공물이 생깁니다. – RamblinRose