계층화 아키텍처의 어려움

요 전날 DDD 책에서 소개된 계층화된 아키텍처는 위의 그림과 같이 모델이 인프라에 의존하고 있다고 썼습니다.

예를 들어 어떤 시간에 그렇게 되는가 하면, 어떤 오브젝트가 어플리케이션 전체로 일의인 것을 확인하기 위해서, 모델이 인프라에 문의해, DB내의 테이블을 검색하는 등등. . .

그럼 어떻게 할까. 몇몇 후보가 「실천 도메인 구동 설계 」로 소개되고 있으므로, 잠시 동안 이쪽을 읽어 가려고 생각합니다.

기타 옵션 DI 사용

상위 모듈은 하위 모듈에 의존해서는 안됩니다. 두 모듈 모두 추상에 의존해야합니다. 추상은 구현의 세부 사항에 의존해서는 안됩니다. 구현의 세부 사항은 추상에 의존해야합니다. (구현 도메인 구동 설계 4.2 레이어에서)

앞의 예

특정 객체가 애플리케이션 전체에서 고유한지 확인하기 위해 모델이 인프라에 문의하여 DB에서 테이블을 검색합니다.

라고 말하면, 모델은 인터페이스인 Repository 를 호출해, 그 구현은 인프라스트럭쳐로 되어 있습니다만, DI 를 사용해 인프라의 구현 자체는 모델로부터 은폐시킵니다.

아래 소스 코드의 예입니다.

(DI 사용 전)

SomeModel.java

// domain層
public SomeModel{
  // infrastractureに依存している
  Repository repository = new SomeInfrastracture();

  public isExist(){
    repository.find();
  }
}

interface Repository{
  find();
}

public SomeInfrastracture implements Repository{
  @override
  find(){・・・｝
}

(DI 사용 후)

SomeModel.java

// domain層
public SomeModel{
　　　// 依存性注入によりinfrastractureの依存が隠蔽された
  @Autowired
  Repository repository

　　　　public isExist(){
    repository.find();
  }
}

interface Repository{
  find();
}

// infrastracure層
@Repository
public SomeInfrastracture implements Repository{
  @override
  find(){・・・｝
}

또한 위의 그림이지만 책으로 표시된 그림보다 더 간단하게 만들었습니다.
자신의 이전 경험으로 인프라가 사용자 인터페이스를 사용하지 않았으며 응용 프로그램을 사용하지 않았습니다.

또, 도서에서는 유저 인터페이스는 도메인을 이용하지 않는 것 같은 그림이 되어 있었습니다만, 유저 인터페이스로부터의 데이터를 모델로 변환하는 책무를 어플리케이션 레이어가 지고 있는 것입니까. . .

자신이 이용해온 SpringFramework에서는 유저 인터페이스(SpringFramework에서는 Controller)로 자동적으로 모델로 변환해 주기 때문에, 유저 인터페이스가 모델을 사용하고 있는 그림이 되고 있습니다.

어쨌든 중요한 것은 모델이 어디에도 의존하지 않는다는 것입니다.