우리는 사용자 관리를 위해 IT 서비스 및 HR 서비스를 개발하는 중이지만 프로젝트를 구성하는 최선의 방법을 결정하는 데 어려움을 겪고 있습니다.nservicebus 솔루션을 구성하는 가장 좋은 방법은 무엇입니까?
하나의 개발자는 IT 프로젝트와 HR 프로젝트를 전복으로 구분해야하며 각 메시지 프로젝트에 SVN 외부 객체를 사용해야한다고 생각합니다.
또 다른 개발자는 같은 Subversion 프로젝트에 넣어야하지만 폴더별로 파일을 분할하는 all.sln, hr.sln 및 it.sln을 사용하여 서비스를 분할해야한다고 생각합니다.
이러한 서비스 경계를 분할하는 가장 좋은 방법은 무엇입니까?
저는 서브 버전에 너무 익숙하지 않지만, 일반적으로 소스 제어 포스트 빌드에 체크인 된 서비스들 사이의 의존성을 가지고 있으며 이후에 각각의 서비스로 분기됩니다. 그 이유는 각 서비스가 새로운 버전의 공유 종속성을 언제 독립적으로 사용할 수 있도록하기 위해서입니다. 분기 연산을 사용하면 종속성의 전체 내역을 가지며 언제든지 롤백 할 수 있습니다. 또한 동일한 종속성의 다른 버전으로 서비스를 제공 할 수 있습니다. 이후 서비스 브랜치에서는 다양한 버전의 종속성을 가질 수 있습니다.
메시지 어셈블리를 체크 인하 고 각 서비스로 분기 (병합)합니다. 거기에서 필요에 따라 새 버전을 사용할 수 있습니다.
이것은 전형적인 순환 종속성 문제와 같습니다. IT 서비스가 HR 서비스에 의존하는지 또는 그 반대인지 아니면 둘 사이에 양방향 통신이 필요한지를 아는 것이 중요합니다. 하나가 다른 것에 의존한다면, 나의 추천은 두 가지 해결책을 갖는 것이다. IT가 HR에 의존한다고 가정 해 보겠습니다. 그런 다음 인사 부서에서 메시지로 표시해야하는 이벤트 또는 명령을 포함하여 도메인 개체 및 인터페이스를 정의하는 핵심 프로젝트를 가질 수 있습니다. Core는 NServiceBus 또는 솔루션의 다른 프로젝트를 참조하지 않습니다. 동일한 솔루션 내에서 Core를 참조하는 HR.Infrastructure 프로젝트가있을 수 있습니다. 이 내에서 메시지를 정의하여 코어의 이벤트 및 명령을 상속하고 NServiceBus.IMessage (따라서 NServiceBus를 참조)를 구현할 수 있습니다. 이제 IT 담당자는 HR.Core 및 HR.Infrastructure를 참조하여 메시지를 처리 할 수 있습니다.
양방향 통신이 필요한 경우 메시지를 자신의 솔루션/프로젝트에 끌어다 놓고 Infrastructure 프로젝트를 두 가지 모두 사용하거나 참조해야합니다. 핵심 프로젝트에서이를 참조하지 않아야합니다. 그러면 코어에서 NServiceBus에 대한 종속성 체인이 생길 수 있으므로 피하려는 것입니다. 이상하게 보일 경우 Onion Architecture 및 Dependency Inversion Principle을 읽고 어떻게 수행되는지 확인하십시오.