본문 바로가기

로버트 C. 마틴(Robert C. Martin)38

클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 6부 : 세부사항 (30장) [6부] 세부사항 [30장] 데이터베이스는 세부사항이다 아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아니다. 즉, 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없다. 소프트웨어 시스템의 아키텍처와 데이터베이스의 관계를 건물로 비교하면 건물의 아키텍처와 문 손잡이의 관계와 같다. 애플리케이션 내부 데이터의 구조는 시스템 아키텍처에서 대단히 중요하다. 하지만 데이터베이스는 데이터 모델이 아니다. 데이터베이스는 일개 소프트웨어일 뿐이다. 데이터베이스는 데이터에 접근할 방법을 제공하는 유틸리티다. [관계형 데이터베이스] 데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처의 외부 원에 위치한 최하위 수준의 유틸리티 함수만 알아야 한다. 많은 데이터 접근 프레임워크가 테이블과 행이 객.. 2020. 3. 24.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 5부 : 아키텍처 (29장) [29장] 클린 임베디드 아키텍처 "소프트웨어는 닳지 않지만, 펌웨어와 하드웨어는 낡아 가므로 결국 소프트웨어도 수정해야 한다." - 더그 슈미트 → 소프트웨어는 닳지 않지만, 펌웨어와 하드웨어에 대한 의존성을 관리하지 않으면 안으로부터 파괴될 수 있다. 임베디드 엔지니어가 아닌 당신도 코드에 SQL을 심어 놓거나 개발하는 코드 전반에 플랫폼 의존성을 퍼뜨려 놓는다면, 본질적으로 펌웨어를 작성하는 셈이다. 오래전부터 소프트웨어를 하드웨어로부터 분리할 필요성을 느끼고 또 이해하고 있었지만... 엔지니어와 프로그래머에게 전하는 메시지는 분명하다. 펌웨어를 수없이 양산하는 일을 멈추고, 코드에게 유효 수명을 길게 늘릴 수 있는 기회를 주어라. [앱티튜드 테스트(App-titude test)] 켄트벡은 소프트웨.. 2020. 3. 23.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 5부 : 아키텍처 (28장) [28장] 테스트 경계 테스트는 시스템의 일부이며, 아키텍처에도 관여한다. [시스템 컴포넌트인 테스트] 단위 테스트, 통합테스트, 인수 테스트, 기능 테스트, Cucumber 테스트, TDD 테스트, BDD 테스트, 컴포넌트 테스트. 아키텍처 관점에서는 모든 테스트가 동일하다. 테스트는 태생적으로 의존성 규칙을 따른다. 테스트는 세부적이며 구체적인 것으로, 의존성은 항상 테스트 대상이 되는 코드를 향한다. 실제로 테스트는 아키텍처에서 가장 바깥쪽 원으로 생각할 수 있다. 시스템 내부의 어떤 것도 테스트에는 의존하지 않으며, 테스트는 시스템의 컴포넌트를 향해, 항상 원의 안쪽으로 의존한다. 또한 테스트는 독립적으로 배포 가능하다. 테스트의 역할은 운영이 아니라 개발을 지원하는 데 있다. [테스트를 고려한 .. 2020. 3. 22.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 5부 : 아키텍처 (27장) [27장] '크고 작은 모든' 서비스들 서비스 지향 '아키텍처'와 마이크로서비스 '아키텍처' [서비스 아키텍처?] 시스템의 아키텍처는 의존성 규칙을 준수하며 고수준의 정책을 저수준의 세부사항으로부터 분리하는 경계에 의해 정의된다. 서비스 그자체로는 아키텍처를 정의하지 않는다. 모노리틱 시스템이나 컴포넌트 기반 시스템에서 아키텍처를 정의하는 요소는 바로 의존성 규칙을 따르며 아키텍처 경계를 넘나드는 함수 호출들이다. 결국 서비스는 프로세스나 플랫폼 경계를 가로지르는 함수 호출에 지나지 않는다. [서비스의 이점?] 시스템을 서비들로 분리함으로써 얻게 되리라 예상되는 큰 이점 하나는 서비스 사이의 결합이 확실히 분리된다는 점이다. 모든 서비스의 인터페이스는 반드시 잘 정의되어 있어야 한다. 서로 공유하는 데이.. 2020. 3. 21.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 5부 : 아키텍처 (26장) [26장] 메인(Main) 컴포넌트 모든 시스템에는 최소한 하나의 컴포넌트가 존재하고, 이 컴포넌트가 나머지 컴포넌트를 생성하고, 조정하며, 관리한다. 나는 이 컴포넌트를 메인(Main)이라고 부른다. [궁극적인 세부사항] 메인 컴포넌트는 궁극적인 세부사항으로, 가장 낮은 수준의 정책이다. 메인은 모든 팩토리(Factory)와 전략(Strategy), 그리고 시스템 전반을 담당하는 나머지 기반 설비를 생성한 후, 시스템에서 더 높은 수준을 담당하는 부분으로 제어권을 넘기는 역할을 맡는다. 의존성 주입 프레임워크를 이용해 의존성을 주입하는 일은 바로 이 메인 컴포넌트에서 이뤄져야 한다. 메인에 의존성이 일단 주입되고 나면, 메인은 의존성 주입 프레임워크를 사용하지 안혹도 일반적인 방식으로 의존성을 분배할 .. 2020. 3. 20.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 5부 : 아키텍처 (25장) [25장] 계층과 경계 시스템이 세 가지 컴포넌트(UI, 업무 규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다. 예를 들어 간단한 컴퓨터 게임을 생각해보자. UI는 플레이어가 입력한 메시지를 모두 게임 규칙으로 전달한다. 게임 규칙은 게임의 상태를 영속성을 가지는 특정한 데이터 구조로 저장한다. [움퍼스 사냥 게임] 게임 규칙은 언어 독립적인 API를 사용해서 UI 컴포넌트와 통신할 것이고, UI는 API를 사람이 이해할 수 있는 언어로 변환할 것이다. 우리는 게임 규칙이 다양한 종류의 데이터 저장소에 대해 알지 않기를 원한다. [클린 아키텍처?] 분명하게 이 예제의 맥락이라면 클린 아키텍처 접근법을 적용해서 유스케이스, 경계, 엔티티, 그리고 관련된 데이터 구조를 모두 만드는 일도 쉬운 일이다. 정보.. 2020. 3. 19.