나는 본질적으로 매우 모듈화 된 새로운 솔루션을 설계하고 미래의 쉬운 확장, 명확한 문제 분리, 모듈 별 라이센싱 등을 가능하게하는 디자인을 지원하는 구조를 만들고 싶습니다. 웹에서 모듈 식 또는 복합 응용 프로그램에 대해 UI 중심이며 Silverlight, WPF 등에 중점을 둡니다. 필자의 경우 다양한 UI 프로젝트를 수행하는 다른 개발자가 사용할 WCF 서비스 응용 프로그램을 개발 중입니다.
배경
내 프로젝트의 목표는 현재 프로세스, 규칙 등을 복제하는 여러 비즈니스 응용 프로그램을 지원하기 위해 중앙 집중식 비즈니스 / 도메인 로직 소스를 만드는 것입니다. 모듈화의 모든 이점을 달성 할 수는 없지만, 우리가 활용할 수있는 부분을 활용할 프레임 워크를 구축 할 기회.
서비스 응용 프로그램에 의해 노출 된 API를 살펴봄으로써 디자인을 시작했습니다. 내가 고려하고있는 모듈 식 라인을 따라 서비스를 분리 할 수 있다는 것은 분명하다. 예를 들어, 서비스를 그룹화하여 FinanceService, InventoryService, PersonnelService 등의 서비스를 제공하여 API에서 높은 결속력을 제공하는 동시에 커플 링은 낮게 유지하므로 클라이언트는 응용 프로그램과 관련된 서비스 만 사용해야합니다.
그런 다음 MyApp.Finance, MyApp.Inventory, My.Personnel 등과 같은 각 서비스에 대해 별도의 모듈을 가질 수 있다는 것이 의미가 있습니다. 교차 절단 문제 및 공유 유형은 MyApp 공유 어셈블리에 있습니다. 여기에서 나는 조금 묶여있다.
(Oh, 나는 의존성 주입을 위해 IoC 컨테이너를 사용하여 응용 프로그램을 느슨하게 결합 할 것이라고 언급해야합니다. Pandora의 상자를 열고 싶지 않기 때문에 어느 것을 언급하지 않을 것입니다!)
MyApp.ServiceHost에서 예를 들어 FinanceService.svc와 같은 각 모듈에 해당하는 서비스 호스트 파일 (.svc)을 만듭니다. 서비스 호스트에는 서비스 계약을 정의하는 인터페이스가 포함 된 구성 파일의 정보에 해당하는 서비스 이름이 필요합니다. 그런 다음 IoC 구성을 사용하여 사용할 인터페이스의 구체적인 구현을 매핑합니다.
1. 서비스 계층이 API를 구현하고 모듈에 위임해야합니까 (또는 모듈이 서비스 구현을 포함하여 해당 모듈과 관련된 모든 것을 포함하고 있음) 자체적으로 포함해야합니까?
이 문제에 접근하는 한 가지 방법은 서비스 계약의 구현을 포함하는 MyApp.Services "모듈"을 갖는 것입니다. 각 서비스 클래스는 단순히 작업에 대한 도메인 로직을 포함하는 적절한 모듈에 다른 클래스에 위임합니다. 예를 들어 MyApp.Services의 FinanceService WCF 클래스는 작업을 수행하기 위해 Finance 모듈에 구현 된 다른 인터페이스에 위임합니다. 이를 통해 얇은 서비스 파사드를 유지하고 구현을 서비스 구현에 '플러그인'하고 모듈이 WCF에 대해 걱정할 필요가 없습니다.
반면에, 인터페이스와 구현을 가지고 있다는 점에서 각 모듈을 독립적으로 유지하는 것이 좋습니다. 서비스 호스트는 모듈에있는 서비스 계약 인터페이스를 말하며 IoC는 모듈에서 적절한 구현을 사용하도록 구성됩니다. 이는 새 .svc 파일 및 IoC 구성 정보를 추가하는 것 외에는 서비스 계층을 변경하지 않고 새 모듈을 추가 할 수 있음을 의미합니다.
표준 WCF에서 RESTful 서비스 인터페이스로 전환하거나 RIA 서비스 또는 다른 것으로 갈 경우의 영향에 대해 생각하고 있습니다. 각 모듈에 서비스 계약의 구현이 포함되어 있으면 서비스 기술이나 접근 방식을 변경하면 모든 모듈을 변경해야합니다. 그러나 파사드가 자체 모듈 인 경우 변경하기 위해 해당 부분 만 교체하면됩니다. 그러면 모듈은 공유 어셈블리에 정의 된 다른 계약 세트 (인터페이스)를 구현해야합니까?
2. 모듈 간 및 / 또는 모듈 간 종속성 공유를 처리하는 가장 좋은 방법은 무엇입니까?
예를 들어, 수신 조작을 수행하십시오. 처음에는 상품 입고가 재고 기능이므로 재고 모듈로 들어가는 것이 좋습니다. 그러나 영수증을 생성하고 지불을 승인해야한다는 측면에서도 재정적 인 측면이 있습니다.
On the one hand, I would expect to use some type of domain events / messaging to communicate the operation. The Inventory module raises a GoodsReceivedEvent which is handled by the Financial module to generate the Receipt and initiate the payment process. However, this means that the Financial module needs to know about the inventory items that were received. I can simply refer to them by ID but what if I need additional information for the Receipt, such as the name and/or description, unit cost, etc.? Does it make sense for each module to have their own version of an inventory item that is designed to suit the needs of that module? In that case, the Financial module would have to perform its own lookup of the inventory items when handling the GoodsReceivedEvent. Or do I now have to put my domain objects into a shared location (at which point I lose some cohesion)?
...
다양한 ERP 시스템에서 많은 작업을 해왔고 이러한 유형의 모듈로 설계 되었기 때문에이 예제를 의도적으로 사용했습니다. 또한 위에서 명시 적으로 언급하지는 않지만 솔루션을 설계 할 때 도메인 기반 디자인 원칙을 따르는 것을 선호하며 이러한 유형의 모듈성은 해당 영역에 적합하다고 생각합니다.
내 머리를 감싸는 데 도움을 주시면 감사하겠습니다.