본문 바로가기

SearchDeveloper/클린 아키텍처

 (11)
[11] 33~34 사례 연구: 비디오 판매 23.11.4 [33] 사례 연구: 비디오 판매 개인과 기업에게 판매한다. 개인은 구매자인 동시에 시청자이고, 스트리밍 혹은 영구 소지할 수 있다. 기업은 구매자와 시청자가 다르고, 스트리밍만 된다. 액터 기준으로 경계가 나뉨 -한 액터 기능이 변경되도 다른 액터에게 영향 없도록 -제작자, 관리자, 구매자, 시청자 -카탈로그 조회(View Catalog) 는 추상 클래스이다. 비슷한 기능이라서. 구매자, 시청자 단에서 각각 구현해줌. 컴포넌트 아키텍처 -검정 화살표: 상속관계 / 빈 화살표: 제어 흐름. 고수준을 향해 있다. -컨트롤러로 입력이 들어오면 interactions 에 의해 데이터가 만들어지고, 그 이후에 Presenters 가 결과 포맷 변경하고 Views 가 화면에 표시한다. -Catalo..
[10] 30~32 세부사항 23.10.29 [30] 데이터베이스는 세부사항이다 DB는 그저 매커니즘에 불과하며 디스크 표면과 RAM 사이에서 데이터를 이리저리 옮길 때 사용할 뿐이다. 실제로 비트를 담는 거대한 그릇이며, 데이터를 장기적으로 저장하는 공간에 지나지 않는다. 그러므로 세부사항인 DB 를 아키텍처 중심에 두어서는 안되며, 즉 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다니게 허용하면 안된다. ※ DB 가 널리 사용되는 이유 디스크에 있는 데이터를 접근하는 건 너무 느리기 때문에, 시간 지연을 완화하기 위해 색인, 캐시, 쿼리 계획 최적화 같은 것들이 필요해졌는데 그럴러면 원천 데이터가 있는 곳이 필요했다. 그래서 문서 기반의 파일 시스템, 내용 기반의 DB 시스템이 출현했다. 파일 시스템은 파일을 편리하게 저장..
[9] 27~29 서비스 기반 아키텍처 vs. 컴포넌트 기반 아키텍처 23.10.23 [27] ‘크고 작은 모든' 서비스들 서비스 기반 아키텍처 vs. 컴포넌트 기반 아키텍처 서비스 아키텍처의 통설 및 이의 통설 1) 서비스 사이의 결합이 철저하게 분리된다. 이의 제기) 결합 분리의 오류 어느 정도 일리는 있지만 서비스 단위로 다른 프로세서에서 실행되고, 다른 서비스 변수에 직접 접근할 수 없고, 인터페이스는 잘 정의되어있어야 한다. 꼭 그런 것만은 아니다 서비스들이 한 장비 내에 존재한다면 네트워크 상의 공유 자원 때문에 결합될 가능성이 여전히 존재한다. 서비스는 분리해도 DB 를 공유하면 DB 데이터가 변경됐을 때 관련된 모든 서비스들이 변경돼야 한다. 통설 2) 개발 및 배포 독립성을 지원한다. 이의 제기) 개발 및 배포 독립성의 오류 어느 정도 일리가 있지만 대규모..
[8] 24~26 경계 23.10.10 [24] 부분적 경계 완벽한 경계를 만들기엔 비용과 노력이 너무 많이 들므로(쌍방향 바운더리 인터페이스, input/output 데이터 구조, 컴포넌트 격리), 부분적 경계를 활용해 볼 수도 있다. 부분적 경계 구현 방법 3가지 1. 마지막 단계를 건너뛰기 마지막 단계: 다중 컴포넌트로 각각 배포하는 것 같음 독립적으로 컴파일하고 배포할 수 있는 컴포넌트 만드는 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 둔다. 컴파일이랑 배포도 단일 컴포넌트로 한다. 그래도 완벽한 경계를 만들 때만큼의 코드량과 설계 비용은 많이 들지만, 버전 번호나 배포 관리 부담이 없는 차이가 있다. 사례) Fitnesse 만들 때 초기 전략으로 웹 컴포넌트를 분리했으나 한 번에 다운로드하는게 목적이기도 ..
[7] 20~23 업무규칙 & 아키텍처 23.09.23 [20] 업무 규칙 애플리케이션 = 업무 규칙 + 플러그인 업무 규칙 = 엔티티 + 유스케이스 업무 규칙이란? 사업적으로 수익을 얻거나 비용을 줄일 수 있게 하는 규칙. 컴퓨터상으로 어떻게 구현하는지 또는 규칙을 자동화하는 시스템과는 상관없다. ex. 대출에 N% 의 이자를 부과한다. 업무 규칙은 대출 잔액, 이자율, 지급 일정 같은 핵심 데이터와 본질적으로 결합되어 있기 때문에 엔티티라는 객체 형태로 관리하기 좋다. 엔티티 : 컴퓨터 시스템 내부의 객체로서, 핵심 업무 데이터 기반으로 동작하는 조그만 핵심 업무 규칙을 구체화한다. -순전히 업무에 대한 것이어야 한다. -이런 핵심적인 개념 구현하는 소프트웨어는 한 데 모으고, 세부 규칙(DB, 사용자 인터페이스, 서드 파티 프레임워크) ..
[6] 17~19 경계 23.09.19 [17] 경계: 선 긋기 소프트웨어 아키텍쳐는 선, 즉 경계를 긋는 기술이다. 아키텍트의 목표는 시스템을 만들고 유지하는데 드는 인적 자원을 최소화하는 것인데, 너무 경계를 일찍 그어버리면 오히려 더 들 수 있다. 일찍 경계를 긋는다는 것: 시스템의 업무 요구 사항, 즉 유즈 케이스와 관련 없은 프레임워크, DB, 웹 서버 등 세부사항을 미리 결정하는 것 나쁜 사례 자사 제품을 웹 버전으로 변환하는 프로젝트 착수. 서버 팜(여러개 서버)을 예상하고 GUI, 미들웨어, DB 가 각각 다른 서버에 있을 것이라 생각하고 개발함. 티어 간 통신이 필요하기 때문에 필드 하나만 추가하려고 해도 통신하기 위해 양방향 4개의 메시지와 8개의 핸들러를 수정해야했음. (변경이 어려움) 그런데 정작 배포하는..
[5] 15~16 아키텍처와 독립성 2023.09.15 아키텍처란? 소프트웨어 아키텍트가 하는 일 프로그래머이다. 설계만 하는 사람이 아니라 계속 개발하면서 팀원들이 좋은 방향으로 설계할 수 있도록 이끌어준다. 그 모양은 컴포넌트를 어떻게 분할하고 배치하고 서로 의사소통하는 방식에 의해 결정된다. 시스템의 동작 여부와는 관련없다. 좋지 않은 아키텍처로도 돌아가게 만들 수는 있기 때문이다. 좋은 아키텍처를 만드려는 궁극적인 목표는 시스템 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하기 위함이다. 그러려면 시스템을 쉽게 이해하고 개발하고 유지보수하고 배포할 수 있어햐한다. 이런 일을 용이하게 만들기 위해서는 가능한 많은 선택지를 오래 남겨두는 전략을 따라야 한다. 개발 팀 규모에 따라 아키텍팅도 다르다. 팀이 5명 정도로 작..
[4] 12~14 컴포넌트 컴포넌트의 역사 : 내가 생각했을 땐 분리의 역사 소프트웨어 개발 초창기에는 어떤 메모리 주소에 프로그램을 로드할 건지도 일일히 정해줘야 했었다. 라이브러리 함수도 직접 애플리케이션 코드에 포함해서 단일 프로그램으로 컴파일해야 했다. 그러다가 프로그램 사이즈도 너무 커지고 컴파일에도 오래 걸리니 앺 코드와 라이브러리 코드를 메모리 상에서 분리했다. 메모리 주소 몇 이상은 라이브러리 같은 규칙을 정하고 말이다. 그러면 라이브러리 따로 개별적으로 컴파일할 수 있었지만, 앺 코드가 너무 커지면서 라이브러리 밑에 집어넣는 비효율이 발생했다. 메모리 주소를 고정이 아닌 재배치를 하는게 해결책이었다. 그 기능을 로더가 해준다. 앺과 라이브러리를 로드할 위치를 로더에게 전달해주면 그에 맞게 컴파일러를 수정한다. 로더..
[3] 8~11장 SOLID SRP(Single Response Principle) 어떻게 하라고? 변경을 요청하는 주체(액터)가 다르면, 코드를 분리해라 왜? 액터가 다른데 같은 코드를 썼다간 다른 팀 모르게 수정될 가능성이 있음 코드 병합할 때 어려움 OCP(Open Closed Principle) 어떻게 하라고? 기능을 확장할 때는 코드 수정이 아니라 코드를 추가하는 방향으로 간다. 왜? 변경을 쉽게 처리하되 시스템이 너무 많은 영향 받게 하지 않기 위해 LSP(Liskov Substitute Principle) 어떻게 하라고? 다형성 개발할 때 부모 기능 잘 지켜라 완벽하게 이해하는 LSP (리스코프 치환 원칙) 왜? 변화에 쉽게 하기 위해 ISP(Interface Segregation Principle) 어떻게 하라고? 인..
[2] 3~6장 패러다임 개요 (구조적, 객체지향, 함수형 프로그래밍) 언어의 역사 1945년: 앨런 튜링이 바이너리 언어로 반복분, 분기문, 할당, 서브루틴, 스택 을 활용해 사람이 식별가능한 형태로 프로그램을 코드로 작성 1940년대 후반:“언어” 어셈블리 처음 등장. 바이너리 코드로 짜야했던 프로그래머의 고된일이 줄어듦. 1951년: 최초의 컴파일러 A0 등장. by 그레이스 호퍼 패러다임이란 프로그래밍을 하는 방법. 언제 어떤 프로그래밍 구조를 사용해야 하는지 결정한다. 세 가지 패러다임을 알려주겠다. 구조적 프로그래밍 프로그래밍의 역사 다익스트라는 네덜란드 최초의 프로그래머라는 직업을 가진 사람이다. 다익스트라는 어려운 프로그래밍을 해결하기 위해 증명이라는 수학적인 원리를 적용했다. “프로그래머" 는 입증된 구조를 이용하고, 이 구조를 코드와 결합시켜 코드가 올바름..

티스토리툴바