ADP: 의존성 비순환 원칙
간단히 말하면 컴포넌트 의존성 그래프에 순환이 있으면 안된다는 원칙이다. 최신 스프링 부트 버전에서는 컴포넌트는 아니더라도 빈의 의존성이 순환을 하게 되면 에러를 발생시킨다.
순환 의존성 제거
개발 환경을 릴리스 가능한 컴포넌트 단위로 분리한 후 컴포넌트별로 담당자 또는 담당팀을 지정한다. 컴포넌트가 동작 가능하도록 만들고 릴리스 번호를 부여해 다른 팀에서 사용할 수 있도록 만들면 다른 팀은 해당 컴포넌트를 사용하기만 하면 된다.
만약 새로운 릴리스 버전이 만들어졌다고 하면, 이것을 사용할지 이전 릴리스 버전을 사용할지는 전적으로 사용하는 사람의 몫이다. 따라서 사용하는 팀과 만드는 팀의 결합이 느슨해졌다.
이러한 구조를 잘 사용하기 위해서는 컴포넌트 의존성이 순환하지 않아야 한다.
순환 끊기
의존성 역전 원칙를 적용하자. 인터페이스를 만드는 것이 화살표의 방향을 바꾸거나 새롭게 만드는 가장 좋은 방법이다.
하향식 설계
컴포넌트 구조는 하향식으로 설계될 수 없다. 컴포넌트는 시스템에서 가장 먼저 설계할 수 있는 대상이 아니며, 오히려 시스템이 성장하고 변경될 때 함께 진화한다.
컴포넌트 의존성 다이어그램은 애플리케이션의 빌드 가능성과 유지보수성을 나타낸다. 화살표가 향하는 곳의 변경사항이 화살표가 출발한 곳에 영향을 준다. 따라서 처음 컴포넌트를 설계할 때 하향식 설계는 할 수 없다.
SDP: 안정된 의존성 원칙
설계는 불완전하다. 컴포넌트도 언제든 변할 수 있고 모든 아키텍처가 변경될 수 있다. 그러므로 최대한 안정적이지 않은 것(자주 변하는 것)이 안정적인 것(변화가 없는 것)에 의존하도록 설계해야 한다.
SAP: 안정된 추상화 원칙
컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
비즈니스 로직이나 아키텍처와 관련된 결정에는 변동사항이 최대한 없기를 기대한다. 따라서 고수준 정책을 다루는 컴포넌트는 반드시 안정된 컴포넌트에 위치해야 한다. 그러나 안정된 컴포넌트에 있는 고수준 정책을 수정해야 하는 상황이 발생하면 이는 큰 재앙이 뒤따른다. 이를 해결하기 위해서 OCP를 고려해서 만들어야 한다.
안정된 추상화 원칙은 안정성과 추상화 정도 사이의 관계를 나타낸다. 안정된 컴포넌트는 추상 컴포넌트여야 하고 안정성이 컴포넌트를 확장하는데 방해가 되어서는 안된다.
