소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
즉, 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 산출물을 변경해서는 안된다.
📕 사고 실험
소프트웨어 아키텍처가 훌륭하다면, 변경되는 코드의 양이 가능한 한 최소화 될 것이다. 이상적인 변경량은 0 이다.
변경되는 요소를 적절하게 분리하고 (SRP), 이 요소들 사이의 의존성을 체계화하면(DIP) 변경량을 최소화 할 수 있다.
책임을 분리하게 되면 변경이 발생하더라도 다른 하나는 변경되지 않도록 의존성을 확실하게 한다.
또한, 행위가 확장될 때 변경이 발생하지 않음을 보장해야 한다.
이를 위해서는 처리 과정을 클래스 단위로 분할하고 클래스를 컴포넌트 단위로 구분해야 한다.
- < I > : 인터페이스
- < DS > : 데이터 구조
- 화살표가 열려있다면 사용관계
- 화살표가 닫혀있다면 구현 또는 상속 관계
위 그림에서 FinancialDataMapper은 구현관계를 통해, FinancialDataGateway를 알고 있지만, FinancialDataGateway는 FinancialDataMapper를 알지 못한다.
위 그림에서의 화살표는 변경으로부터 보호하려는 컴포넌트를 향하도록 그려진다. (단방향)
- Presenter에서 발생한 변경으로 부터 Controller을 보호하고자한다.
- View에서 발생한 변경으로 부터 Presenter을 보호하고자한다.
- Interactor는 모든 것에서 발생한 변경으로부터 보호하고자 한다.
- Interactor는 어떠한 변경에도 영향 받지 않는다.
- 가장 높은 수준의 정책을 포함한다.
아키텍트는 기능이 어떻게, 왜, 언제 발생하는지에 따라 기능을 분리하고, 분리한 기능을 컴포넌트의 계층구조로 조직화 한다.
- 저수준의 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있다.
📗 방향성 제어
FinancialDataGateway 인터페이스는 FinancialReportGenerator와 FinancialDataMapper 사이에 위치하는데, 이는 의존성 역전시키기 위해서 이다.
- 컴포넌트간 의존성의 방향을 확실히 해야한다.
- 의존성을 역전시켜 고수준의 컴포넌트를 보호한다.
📙 정보 은닉
FinancialReportRequester는 정보은닉의 목적을 가진다.
FinancialReportController가 Ineractor 내부에 대해 너무 많이 알지 못하도록 막기 위해서 존재한다.
이게 없었다면, Controller는 FinancialEntities에 대해 추이 종속성을 가지게 된다.
Controller에서 발생한 변경으로부터 Interactor를 보호하는 일이 우선순위 지만, 반대로 Interactor에서 발생한 변경으로부터 Controller도 보호되기 바라기 때문에, Interactor의 내부를 은닉한다.
* 추이 종속성 : A가 클래스 B를 의존하고, 다시 클래스 B가 클래스 C에 의존한다면, 클래스 A는 클래스 C에 의존하게 된다.
📘 OCP
시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 한다.
- 시스템을 컴포넌트 단위로 분리하고, 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조를 이뤄야 한다.
📚 Reference
- Clean Architecture : 소프트웨어 구조와 설계의 원칙
