.net 논리적 계층 아키텍처 요약

1. 기본 지식 준비:

1. 레이어의 원리:

(1) 각 레이어는 상위 레이어의 호출을 위한 인터페이스를 사용합니다.
(2) 상위 레이어는 하위 레이어만 호출할 수 있습니다.
(3) 종속성은 느슨한 상호작용과 엄격한 상호작용의 두 가지 유형으로 나뉩니다.

2. 비즈니스 로직 분류:

(1) 애플리케이션 로직.
(2) 도메인 로직.

3. 채택된 레이어:

(1) 프리젠테이션 레이어(사용자 인터페이스 레이어): 도메인 독립적입니다.
(2) 서비스 레이어(애플리케이션 레이어): 애플리케이션 로직.
(3) 비즈니스 로직 레이어(도메인 레이어): 도메인 로직.
(4) 공유 레이어: 공통 코드를 제공합니다.
(5) 구현 계층: 인터페이스 구현을 제공합니다.

4. 계약:

(1) 도메인 계층은 기본적으로 도메인 모델을 사용합니다.
(2) 데이터 액세스 계층은 기본적으로 도메인 모델을 참조해야 합니다.

2. 계층형 아키텍처

계층형 아키텍처의 세 가지 기본 수준은 프레젠테이션 계층, 비즈니스 로직 계층 및 데이터 액세스 계층입니다. 비즈니스 로직 계층을 비즈니스 로직 분류에 따라 서비스 계층과 도메인 계층으로 분해하면 3개 계층은 프레젠테이션 계층, 서비스 계층, 도메인 계층, 데이터 액세스 계층의 4개 계층으로 확장됩니다. 데이터 액세스 계층은 일반적으로 계층 간에 양방향 종속성을 생성하는 도메인 모델을 이해해야 합니다. 일반적으로 다음 두 가지 솔루션이 있습니다.

　1. 공유 계층에 도메인 모델을 배치합니다.

평가: PetShop에서 이 모델을 채택했지만 많은 단점이 있습니다. 비즈니스 로직 계층은 이름에 걸맞지 않으며 도메인 모델은 실제로 계층 간을 유지하는 데이터 모델입니다. 이는 도메인을 핵심으로 하는 것이 아니라 명백한 데이터 기반 아이디어입니다.

2. 비즈니스 로직 계층에서 데이터 액세스 인터페이스 정의:

평가: NopCommerce는 이 모델을 채택합니다. 분리됨 서비스 계층이 제거되고 리소스 라이브러리 명명 방법이 채택되었습니다. 그러나 NopCommerce는 DDD 계층 아키텍처가 아니라 도메인 모델 및 인터페이스 분리 원칙을 채택하는 일반적인 3계층 아키텍처입니다. 단점: 데이터 공간 외에 다른 특정 기술 종속성은 비즈니스 논리 계층과 분리되지 않습니다.

3. DDD 계층화:

DDD 계층화는 비즈니스 로직 계층을 애플리케이션 계층(서비스 계층)과 도메인 계층의 두 부분으로 명확하게 나눕니다. 동시에 데이터 액세스 및 기타 인터페이스의 특정 기술 구현 부분은 인프라 계층으로 통합됩니다.

1. 원래 DDD 레이어링:

평가: 장점은 구체적이다 기술 구현이 도메인에서 분리되어 인프라 계층의 재사용 가치가 높아집니다. 단점은 인프라 계층을 세분화하는 데 공유 및 구현 개념이 사용되지 않아 인프라 계층에서 웨어하우징을 구현할 때 역의존성이 발생한다는 점입니다. 단일 프로젝트 솔루션에는 영향을 미치지 않지만(네임스페이스 수준에서는 형식적인 종속성만 있습니다.) ) 그러나 .NET 다중 프로젝트 솔루션에서는 웨어하우징 구현은 인터페이스 분리를 ​​통해 유사한 데이터 액세스 계층으로만 분리될 수 있습니다.

2. 향상된 DDD 계층:

평가: 인프라 계층은 공유 계층과 구현 계층의 특성을 모두 갖습니다. . 장점은 결국 도메인이 공식적으로 핵심이 되고, 인프라 계층에서 웨어하우징을 구현할 때 도메인 모델을 참조할 수 없는 당혹감을 해결하기도 한다는 점입니다. 단점 역시 공유 개념과 구현 개념의 구분이 없다는 점입니다. .

3. 최신 DDD 레이어링:

평가: 이것이 진정한 도메인 중심이라는 장점이 있으며, 인프라 계층이 도메인 계층을 참조할 수 없기 때문에 서비스 계층에서 다시 적응할 필요가 없습니다. 종속성 역전 원칙을 사용하여 특정 기술에 대한 각 계층의 종속성을 완전히 반전시킵니다. 단점: 종속성 반전이 너무 많이 적용됩니다. 단일 프로젝트 솔루션에서도 문제가 되지 않지만 .NET 다중 프로젝트 솔루션에서는 네임스페이스 형태로 양방향 종속성이 발생합니다. 구현 계층으로서 인프라 계층은 기본적으로 재사용 가치가 없습니다. 더 나은 접근 방식은 다이어그램에서 사용자 인터페이스 계층과 인프라 계층의 위치를 ​​바꾸는 것입니다.

필요에 따라 위 이미지에 적절한 공유 레이어를 추가하는 것을 고려할 수 있습니다.

4. 아키텍처 트렌드:

(1) 비즈니스 로직을 핵심으로 삼아 비즈니스 로직에 더 많은 관심을 기울이세요.
(2) 통합 관리를 위해 비즈니스 로직 계층의 특정 종속성을 하나의 수준으로 나눕니다.
(3) 솔루션 간 코드 재사용보다는 솔루션 내 종속성을 줄이는 데 더 주의를 기울이세요.
(4) 공유 레이어와 구현 레이어의 분리가 점점 더 반영될 것입니다. 예를 들어 양파 아키텍처입니다.

참고

1.Enterprise Application Architecture 패턴 [Enterprise Application Architecture 패턴]
2.Domain-Driven Design [Domain-Driven Design: 소프트웨어의 핵심 복잡성을 처리하는 방법 ]
　3.도메인 중심 디자인 및 패턴 적용【도메인 중심 디자인 및 패턴 실습】
　4.도메인 중심 디자인 구현【도메인 중심 디자인 구현】
　5.Microsoft 애플리케이션 아키텍처 가이드【Microsoft 애플리케이션 아키텍처 가이드(제2판)】
　6.Professional Enterprise .NET [.NET 엔터프라이즈 프로젝트 개발에 능숙함: 최신 패턴, 도구 및 방법]
　7.Professional ASP.NET 디자인 패턴 [ASP. NET 디자인 패턴]