.dll 구조 설계를위한 리소스

Question

방금 디자인 회의에서 나왔고 우리가 구축하는 프로젝트의 일부 .dlls를 구성하는 방법에 대한 아이디어 중 하나를 어디에서 얻었는지에 대한 질문이있었습니다. 솔직히 말해서 나는이 "아이디어"가 어디에서 왔는지 전혀 모른다. 그러나 문서화 된 분석으로 이러한 의견을 백업 할 수 있다면 유용 할 것입니다.

어셈블리/모듈/소스를 구조화하기위한 다른 메커니즘에 대해 설명하는 자료를 아는 사람이 있습니까?

업데이트:

그 아이디어는 특별한 것이 아니었다. 우리는 일부 하드웨어에 대한 추상화 계층을 논의하고 있었으므로 이러한 서비스를 소비하는 "앱"은 (일종의) 플랫폼 독립성 일 수 있습니다. 이전에는 앱이 요구하는 인터페이스를 선언하는 인터페이스 .dll과 지금까지 우리가 가지고 있었던 하나의 플랫폼에 대해 구현하는 구현 .dll이 있습니다. 이제 우리는 두 개의 플랫폼이 있지만 매우 비슷합니다. 인터페이스 .dll이 오염되거나 구현이 서로를 참조하는 끔찍한 시나리오를 방지하기 위해 공통 추상적 구현이 살 수있는 인터페이스와 Specipleplatform.dlls 사이에있는 다른 .dll을 작성했다고 제안했습니다.

Answer 1

기회가 있다면 Robert C. Martin의 책을 살펴보십시오.

C#의 민첩한 원리, 패턴 및 관행 (이것은 .net을 대상으로하는 새 버전입니다)

구성 요소 디자인에 전념하는 장이있을 것입니다.

요약하면, 그 책을 읽은 후에는 항상 다음 기준으로 구성 요소를 분리하는 것이 좋습니다.

• 어셈블리는 단위 또는 재사용입니다: 함께 사용해야하는 클래스가 있다면 같은 조립품으로 이동합니다.

• 어셈블리는 변화의 단위입니다: 같은 이유로 변경할 필요가없는 클래스가 있다면 아마도 같은 조립품에있어서는 안됩니다.

• 어셈블리는 배포 단위입니다: 같은 장소에 물리적으로 배치 해야하는 클래스가 있다면 아마도 같은 조립품으로 가야 할 것입니다.

물론 이것들은 단지입니다 휴리스틱 레시피가 아닙니다. 결국 응용 프로그램의 아키텍처 목표 (특히 배포 및 진화/수정을위한 아키텍처 목표)를 기반 으로이 세 가지 디자인 휴리스틱 각각 중 하나를 결정해야합니다.