IT Book Summary/Clean Architecture (16) 썸네일형 리스트형 06세부사항 -4 34장 빠져있는 장 소프트웨어는 올바르게 정의된 경계, 명확한 책임, 통제된 의존성을 가진 클래스와 컴포넌트로 구성되나 디테일(구현 세부사항)을 고려해야 함. 온라인 서점 예제. 설계나 코드 조직화와 관련된 접근법 계층 기반 패키지 전통적 수평 계층형 아키텍처 - 기술적 관점에서 해당 코드가 하는일에 기반해 코드 분할. 웹, 업무 규칙, 영속성 코드를 위해 수평적 계층이 각각 존재. 자바의 경우 계층은 패키지로 구현. OrdersController: 웹 기반 요청 처리. OrdersService: 주문 업무규칙을 정의하는 인터페이스 OrdersServiceImpl: OrdersService 구현체 OrdersRepository: 주문정보에 접근하는 방법 정의하는 인터페이스 JdbcOrdersReposit.. 06 세부사항 - 2 31장 웹은 세부사항이다 끝없이 반복하는 추 연산 능력을 중앙에 집중하는 방식과 분산하는 방식 사이에 끊임없이 움직임. 웸 06 세부사항 -1 30장 데이터베이스는 세부사항이다. 데이터베이스는 세부사항이라 아키텍처의 구성요소 수준으로 끌어올릴수 없음. 애플리케이션 내부 데이터 구조는 아키텍처에서 중요하지만 데이터베이스 모델은 아님. 데이터베이스는데이터에 접근할 방법을 제공하는 유틸리티일 뿐. 관계형 데이터베이스 관계형 테이블은 특정한 형식의 데이터에 접근할때 편하지만, 데이터를 테이블에 행 단위로 배치하는 자체는 중요하지 않음. 데이터 접근 프레임워트가 테이블과 행이 객체형태로 시스템에 산재하는건 잘못된 설계이다. 이렇게하면 유스케이스, 업무규칙, UI 조차 관계형 데이터 구조에 결합된다. 데이터베이스 시스템은 왜 이렇게 널리 사용되는가? 이유는 자기 디스크 데이터 저장소와 다른 형태의 데이터 저장소 형식. 디스크에서 특정바이트를 읽으려면 시간.. 05 아키텍처 - 6 28장 테스트 경계 시스템 컴포넌트인 테스트 테스트의 의존성은 항상 테스트 대상이 되는 시스템의 컴포넌트를 향함. 역할은 운영이 아니라 개발은 지원하는 것. 모든 시스템 컴포넌트가 지켜야하는 모델을 표현해 줌. 테스트를 고려한 설계 시스템에 결합된 테스트는 시스템이 변경될 때 같이 변경되야함. 공통 컴포너트가 변경되면 Fragile Tests Problem 이 생김. 문제를 해결하려면 테스트를 고려해서 설계해야 함. 변동성이 있는것에 의존하지 말라 - 업무규직을 테스트할 수 있게. 테스트 API 테스트가 모든 업무규칙을 검증하는데 사용할 수 있도록 특화 API를 만듬. 시스템을 테스트 가능한 특정 상태로 강제하는 힘. API는 인터랙터 Interactor 와 인터페이스 어댑터 Interface Adapt.. 05 아키텍처 - 5 25장 계층과 경게 시스템을 구축하는 컴포넌트는 UI, 업무규칙, 데이터베이스 컴포넌트 외 그보다 더 많음 움퍼스 사냥 게임 텍스트 기반 사냥 게임. 텍스트 기반 UI는 유지. 게임규칙과 UI를 분리해 다양한 언어로 발매. API를 생성해 게임규칙이 데이터 저장소 컴포넌트와 통신할때 사용. 클린아키텍처? UI에서 언어뿐 아니라 텍스트를 주고받는 매커니즘을 다양하게 할 경우. 언어를 통신 메커니즘으로부터 격리하는 API 생성 점선으로 된 테두리는 API를 정의하는 추상 컴포넌트. 추상 컴포넌트는 아래의 컴포넌트가 구현. API는 구현하는 쪽이 아닌 사용하는 쪽에 정의되고 소속. GameRules 내부 코드에서 사용하고 Language 내부 코드에서 구현하는 다형적 Boundary 인터페이스가 있음. Lan.. 05 아키텍처 - 4 22장 클린 아키텍처 관심사 분리- 소프트웨어를 계층으로 분리. - 최소한 업무규칙을 위한 계층, 사용자와 시스템 인터페이스를 위한 다른계층 하나 포함. 프레임워크 독립성 테스트 용이성. UI 독립성 데이터베이스 독립성. 모든 외부 에이전시 에 대한 독립성 의존성 규칙 보통 안으로 들어갈수록 고수준의 소프트웨어. 바깥쪽 - 메커니즘, 안쪽 -정책 소스코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다. 외부원에 위치한 것은 내부 원에 영향을 주지 않게 해야한다. 엔티티 엔티티는 핵심업무 고수준인 규칙을 캡슐화 함. 해당 애플리케이션의 업무 객체. 유스케이스 유스케이스 계층은 애플리케이션 특화 업무규칙을 포함. 엔티티로 들어오고 나가는 데이터 흐름을 조정. 이 계층에서 발생한 변경이 엔티티에 영향.. 05 아키텍처 - 3 19장 정책과 수준 소프트 웨어 시스템 - 정책을 기술한 것. 아키텍처 개발은 재편성된 컴포넌트들을 비순환 방향 그래프로 구성하는 기술을 포함. 의존성은 소스코드, 컴파일타임의 의존성. 자바의 경우 import, C#에서는 using 구문, 루비에서는 require 구문. 각 컴포넌트를 연결할 때 의존성의 방향이 컴포넌트의 수준을 기반으로 연결되도록 만들어야 함. 저수준 컴포넌트가 고주순 컴포넌트에 의존하도록 설계 수준 level : 입력과 출력까지의 거리 입력과 출력을 다루는 정책이라면 시스템 최하위 수준에 위치하게 함. 소스코드 의존성은 그 수준에 따라 결합되어야 하며, 데이터 흐름을 기준으로 결합되서서는 안됨. function encrypt() { while(true) writeChar(transl.. 05 아키텍처 - 2 16장 독립성 좋은 아키텍처가 시스템에서 지원해야 할 것. 유스케이스 운여 개발 배포 유스케이스 시스템의 아키텍처는 시스템의 의도를 지원해야 한다. 행위를 명확히 하고 외부로 드러내서 이를통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것. 운영 운영지원 관점에서 아키텍처는 요구사항에 맞게 운영작업을 허용할 수 있는 형태로 구조화되야 한다. 아키텍처에서 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않으면, 나중에 운영에 필요한 요구사항이 바뀌더라도 기술 스펙트럼 사이를 전화하는 일이 훨씬 쉽다. 개발 개발환경을 지원하는데 있어 아키텍처는 핵심적인 역할을 한다. Conway 법칙 시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동.. 이전 1 2 다음
