선 긋기

<aside> 💡 소프트웨어 아키텍처는 선을 긋는 기술이며, 이러한 선을 경계라고 함

</aside>

• 경계는 소프트웨어 요소를 서로 분리 / 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막음
• 초기에 그어지는 선들은 최대한 구체적인 것에 대한 결정을 연기시키며, 이를 통해 구체적인 것들이 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적으로 사용 됨
• 결합을 줄임으로써 유지보수에 들어가는 시간이 현저하게 줄어 들 수 있음
  • 너무 일찍 내려진 결합에 대한 결정은 매우 큰 위험요소가 될 수 있음
  • 유즈케이스 ( 업무 요구사항 )와 아무런 관련이 없는 결정 ( DB / 웹서버 / 의존성 주입 )등에 대한 결정이 이러한 결합에 대한 이른 결정의 예시
  • 이런 구체적인 결정에 대해 의존적이지 않은 아키텍처가 좋은 아키텍처이며, 구체적인 결정을 미룰 수 있을 정도로 미룰 수 있는 아키텍처가 좋은 아키텍처
• 실제 겪은 예시를 들며, 이르게 결정된 구체적인 결정들이 유지보수 / 변경에 많은 장애가 됨을 말하고 있음
• 또, 구체적인 결정에 분리된 업무 규칙을 서술하고, 이 구체적인 결정을 최대한 미루는 예시를 들며 구체적인 결정을 미루어 최적의 결정을 내릴 수 있었던 예시를 설명하고 있음

어떻게 / 언제 선을 그어야 하나

• 관련이 있는것 / 없는것에 대해 선을 그어야 한다.

  • GUI와 업무 규칙은 관련이 없기 때문에 반드시 선을 그어야 함

  • 마찬가지로, 데이터베이스도 업무 규칙에 전혀 연관성이 없다.

    • 데이터베이스는 업무 규칙이 간접적으로 사용 할 수 있는 도구인 것이지, 업무 규칙이 스키마 / 쿼리 언어 등에 대해서는 반드시 독립 적이어야 한다는 것을 말함

    • 업무 규칙이 알아야 할 것은, 데이터를 가져오고, 저장 할 떄 쓰이는 인터페이스 ( 함수 집합 ) 정도를 아는 것이 전부

      

      출처 : https://songii00.github.io/2019/10/29/2019-10-28-CleanArchitecture Item 17/

    • 인터페이스를 통해서 호출 할 뿐 database access 구현 클래스를 알고 있는 업무 규칙은 존재하지 않음

  • BusinessRules는 Database가 문제되지 않지만, Database는 BusinessRules에 의존하고 있음

    

    출처 : https://songii00.github.io/2019/10/29/2019-10-28-CleanArchitecture Item 17/

  • Database 컴포넌트는, BusinessRules가 만들어낸 호출을 DB의 쿼리 언어로 변환하는 코드를 담고 있을 뿐임

  • 이러한 DB가 BusinessRules에서는 mySQL이던, sqlite건 상관이 없음

• 위의 DB의 예시와 같이, GUI도 BusinessRules과는 별개로 존재 해야 함
• 즉, 관련성이 낮은 컴포넌트가 관련성이 높은 컴포넌트에 의존함

플러그인 아키텍처

• 위에서 DB / GUI를 보면, 어떤 DB / GUI가 오던 업무 규칙에는 영향이 없음
• 따라서 DB / GUI를 하나의 플러그인 처럼 볼 수 있으며 언제든지 갈아 끼울 수 있게 됨
• 이렇게 분리 해냄으로써 구체적인 구현체가 추상화된 업무 규칙에 영향을 줄 수 없도록 선을 잘 그은 형태가 구현 됨
• 또, GUI의 변경 속도와 업무 규칙의 변경 속도가 다를진데 이러한 분리를 통해 SRP를 구현 해낼 수 있음