ADP: 의존성 비순환 원칙 간단히 말하면 컴포넌트 의존성 그래프에 순환이 있으면 안된다는 원칙이다. 최신 스프링 부트 버전에서는 컴포넌트는 아니더라도 빈의 의존성이 순환을 하게 되면 에러를 발생시킨다. 순환 의존성 제거 개발 환경을 릴리스 가능한 컴포넌트 단위로 분리한 후 컴포넌트별로 담당자 또는 담당팀을 지정한다. 컴포넌트가 동작 가능하도록 만들고 릴리스 번호를 부여해 다른 팀에서 사용할 수 있도록 만들면 다른 팀은 해당 컴포넌트를 사용하기만 하면 된다. 만약 새로운 릴리스 버전이 만들어졌다고 하면, 이것을 사용할지 이전 릴리스 버전을 사용할지는 전적으로 사용하는 사람의 몫이다. 따라서 사용하는 팀과 만드는 팀의 결합이 느슨해졌다. 이러한 구조를 잘 사용하기 위해서는 컴포넌트 의존성이 순환하지 않아야..
clean architecture
REP: 재사용/릴리즈 등가 원칙 재사용 단위는 릴리스 단위와 같다. REP는 당연한 것이다. 한 번에 같이 릴리즈 되어야 하는 클래스들이 한 곳에 뭉쳐야 하고, 이를 지키는 것은 너무나 당연해서 지키지 않았을 때 너무 많이 티가 난다. CCP: 공통 폐쇄 원칙 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어야 한다. 다른 말로 하면 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리해야 한다. CCP는 SRP 단일 책임 원칙을 컴포넌트 단위에서 작성한 것이다. CRP: 공통 재사용 원칙 CRP는 함께 재사용되는 경우가 많은 클래스와 모듈은 한 컴포넌트로 묶어야 한다고 말한다. 개별 클래스가 단독으로 사용되는 경우는 거의 없고 다른 클래스와 상호작용 하는 경우가 많다. CRP를 지키려면..
컴포넌트는 자바의 jar 파일과 같은 배포 단위이다. 여러 컴포넌트를 하나로 묶어서 아카이브로 만들 수도 있고, 각각의 컴포넌트를 독립적으로 배포할 수도 있다. 잘 설계된 컴포넌트는 반드시 독립적으로 배포 및 개발이 가능해야 한다. 프로그램이 커질수록 프로그램을 컴파일하고 실행하는데까지 점점 더 많은 시간이 소요되었다. 그러나 그것보다 더 빠르게 메모리의 속도가 빨라지고 가격이 저렴해지면서 이제는 링크 시간이 초 단위 수준이 되었다. 이후 액티브 X 와 공유 라이브러리 시대가 열렸고 이제는 jar 파일이나 DLL, 공유 라이브러리를 기존 애플리케이션에 플러그인 형태로 배포하는 것이 일상적인 일이 되었다. 현재 이 아키텍처가 컴포넌트 플러그인 아키텍처다.
의존 관계에서 구체적인 모듈을 참조해서는 안되지만 이는 사실상 불가능하다. 자바의 String 클래스가 대표적인 예인데, String 클래스는 구체 클래스이나 대부분의 모듈에서 이에 의존한다. 따라서 우리가 의존하는 것을 피해야 할 것은 변동성이 큰 구체적인 요소이다. 안정된 추상화 인터페이스를 최대한 변경하지 않고 새로운 기능을 추가할 수 있는 방법을 가장 먼저 찾아라. 변동성이 큰 구현체에 의존하는 것을 최대한 피하고 안정된 추상 인터페이스를 의존해야 한다. 변동성이 큰 구체 클래스를 참조하지 말라 추상 팩토리 사용을 고려하라 변동성이 큰 구체 클래스로부터 파생하지 말라 상속은 가장 강력한 결합이다 구체 함수를 오버라이드 하지 말라 구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라 팩토리 소..
