도메인 이름 구동 디자인 입문 Chapter 7~소프트웨어의 유연성을 유지하기 위한 의존 관계 관리를 읽으세요~

※ ※ 본 기사는 나리세 윤선의 저서'메인 드라이브 설계의 입문은 아래에서 위로 알 수 있습니다!도메인 구동 설계의 기본 속 채터 7의 취지를 개인의 견해로 정리한 것입니다.

결론

소프트웨어에서는 참조 개체나 인터페이스만 있으면 종속 관계가 발생합니다.따라서 의존이 생기는 것을 받아들일 수밖에 없다.
원래 유연하게 변경할 수 있는 소프트웨어가 의존으로 인해 쉽게 바뀌지 않도록 의존의 방향성을 제어해 주십시오.

의존 관계를 통제하려면 다음과 같은 두 가지가 매우 중요하다

구체형이 아닌추상형(=활용위치의결합도저하)

제어 의존관계(=생성부분의 결합도 감소)

의존성(예제)
이것은 의존 관계가 발생한 예다.

public interface ICookingMachine {
  Food make();
  Food serve();
}

public class CurryMachine implements ICookingMachine {
  public Food make() {
    System.out.println("カレーを作ります");
    return new Food("カレー");
  }

  public Food serve() {
    System.out.println("作ったカレーを提供します");
    return make();
  }
}

CurryMachine는 ICookingMachine, serve는 make에 달려 있다.

1. 구체형보다는 추상형에 의존한다

Robert C.Martin이 제창한 의존관계 역전의 원칙
High-level modules should not depend on low-level modules. Both should depend on abstractions.
(상급 모듈은 하급 모듈에 의존해서는 안 되고 둘은 추상에 의존해야 한다.)
Abstractions should not depend on details. Details should depend on abstractions.
(추상은 세부적인 실현에 의존해서는 안 된다.세부 사항은 추상에 의존해야 한다.)
*
이 원칙에 따라 구상형에서 구상형을 참조한 도형과 구상형에서 추상형을 참조한 도형은 화살표의 방향이 반전된다.[1]

직접 의존적 상황

추상적으로 의존하는 상황

각 모듈과 같은 층 내에서 추상형을 정의함으로써 하급층에 대한 요구를 결정할 수 있다.
추상형의 위치와 실제 구상형이 같은 층에 있지 않다는 것이 중점이다.
(나는interface와class가 같은 층에 있다고 생각한다...)
결과적으로 Service를 Controller에 직접 사용하는 것보다 결합도가 떨어집니다.
(User Controller의 사양을 변경하지 않고 User Service를 TestUser Service로 바꾸는 것이 쉬워짐)

2. 의존 관계 제어

Service Locator 그래픽과 IoC Container(DI Container) 그래픽에 대해서는 여기. 이해하기 쉬우므로 반드시 읽어야 합니다.
각주
사이트에 따라 리포지토리의 위치도 다르고 설명을 위해 간략한 그림이기 때문에 도면층을 분리해서 쓴다↩︎