[4주차/유리] 워크북 제출합니다

keyword/chapter04/keyword.md

@@ -0,0 +1,200 @@
+- 아키텍처 구조란?
+
+  ### 소프트웨어 아키텍처란?
+
+    - **소프트웨어의 구조**
+    - 소프트웨어의 구조는 소프트웨어의 기본 골격이 되고 소프트웨어를 구성하는 요소의 관계를 표현하는 시스템 구조
+    - 이 아키텍처를 가지고 이해관계자들의 의사소통 도구가 되기도 하고 소프트웨어 아키텍처의 구조에 따라 프로젝트의 성공 실패 여부가 결정되기도 함.
+    1. **모듈화(Modularity):** 소프트웨어의 성능을 향상하거나 시스템의 유지보수가 더 편하도록 시스템을 모듈별로 나누는 작업
+    2. **추상화(Abstraction):** 문제의 포괄적이고 전체적인 개념을 구체화한 후 차례로 세분화하여 구체화시켜나가는 것
+    3. **단계적 분해(Stepwise Refinement):** 하향식 설계 방법
+    4. **정보 은닉(Information Hiding):** 한 모듈 내에 포함된 절차와 자료들의 정보가 감추어져 있어 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
+
+  ### 소프트웨어 아키텍처 패턴이란?
+
+    - 아키텍처를 설계할 때 활용할 수 있는 전형적인 해결 방식 / 예시
+    - 아키텍처 패턴을 사용하면 기본적인 윤곽을 볼 수 있으며 시행착오를 줄이며 고품질의 소프트웨어를 만들 수 있음.
+    1. **Layer Pattern (n-tier Pattern)**
+
+        - 상위 계층은 하위 계층에 대한 서비스 제공자가 되고 하위 계층은 상위 계층의 클라이언트가 됨.
+        - 서로 마주 보고 있는 두 개의 계층에 대해서만 상호작용이 일어나며, 변경 내용이 있을 경우 두 개의 계층에만 영향을 미침.
+        - ex) 데스크톱 애플리케이션에서 많이 사용
+    2. **Client-Server Pattern**
+
+        - 하나의 서버와 다수의 클라이언트로 구성
+        - 클라이언트가 서버에게 서비스를 요청할 경우 서버는 클라이언트에게 적절한 서비스를 제공
+        - 항상 적절한 서비스를 제공하려다 보니 서버는 항상 대기 상태 유지
+        - 요청을 제공하기 위한 동기화 작업을 제외하고는 서로 독립적인 관계를 가짐.
+        - ex) 이메일, 문서 공유, 은행 등 온라인 애플리케이션에 많이 사용
+    3. **Master-Slave Pattern**
+
+        - 마스터가 슬레이브로 작업을 분산해주고 그 후 분산 받은 작업을 처리한 슬레이브들이 다시 마스터로 값을 반환
+        - 특정 슬레이브가 문제가 생기더라도 작업을 여러 슬레이브에 분산하여 진행하기 때문에 큰 문제가 되지 않음
+    4. **Pipe-Filter Pattern**
+
+        - 데이터 스트림을 생성하고 처리하는 각 필터 컴포넌트에서 캡슐화하여 처리되고 처리된 데이터는 파이프를 통해서 전송
+        - 각 필터는 재사용이 되고 필터를 재배치하여 다양한 파이프라인을 만들 수도 있음
+        - 확장성과 용이성 그리고 재사용성 측면에서 높은 강점
+        - ex) 데이터의 변환작업, 동영상 버퍼링에 많이 사용
+    5. **MVC Pattern(Model-View-Controller Pattern)**
+
+        - 3개의 모델로 구성된 컴포넌트
+        - 모델 = 핵심 기능과 데이터를 포함
+        - 뷰 = 사용자에게 정보를 표시 (한 개가 아닐 수도 있음)
+        - ex) 대화형 애플리케이션에 많이 사용
+    6. **Event-Bus Pattern**
+
+        - 4가지 컴포넌트로 구성
+        - 이벤트 소스: 이벤트 버스를 통해서 특정한 채널로 클라이언트가 요청하는 서비스를 전송(이벤트 생성)
+        - 이벤트 리스너: 채널로부터 메시지를 받음 그리고 메시지를 실행함
+        - 채널: 이벤트의 통로
+        - 버스: 채널과 채널 사이의 의사소통이 되도록하는 영역
+        - ex) 안드로이드 개발이나 알림 서비스에 적합
+    7. **Broker Pattern**
+
+        - 브로커가 클라이언트와 서버 사이에 중개 역할을 함
+        - 서비스 호출에 응답하는 컴포넌트가 여러 개 있을 때 중간에서 알선해주고 연결해주는 방식
+        - 보통 분산 시스템에 사용되며 서버가 여러 개 있을 경우 이 패턴을 많이 사용
+    8. **Blackboard Pattern**
+
+        - 결정 가능한 해결 전략이 알려지지 않은 문제에 용이
+        - 3가지 컴포넌트로 구성
+            - 블랙보드: 솔루션 객체를 포함하는 구조화된 전역 메모리
+            - 지식 소스: 자체 표현을 가진 특수 모듈
+            - 제어 컴포넌트: 모듈 선택, 설정 및 실행을 담당
+        - 모든 컴포넌트는 1차적으로 블랙보드에 접근
+        - 컴포넌트는 블랙보드에 추가되는 새로운 데이터 객체를 생성할 수 있음
+        - 컴포넌트는 블랙보드에서 특정 종류의 데이터를 찾으며, 기존 지식 소스와 패턴 매칭으로 데이터를 찾음
+        - ex) 음성인식, 차량 식별, 단백질 구조 식별
+    9. **Interpreter Pattern**
+
+        - 특정 언어를 다른 언어로 번역하거나 해석할 때 사용되는 패턴
+    10. **Peer-to-peer Pattern**
+
+        - 피어 한 개를 컴포넌트로 간주
+        - 피어는 클라이언트가 될 수도 있고 서버가 될 수도 있음
+        - 이 패턴은 추가가 쉬운 패턴이라 추가 확장에 용이
+        - 대신 보안에는 취약한 편이며 피어가 계속 확장되면 서버에도 영향을 미치게 됨
+        - ex) P2P 사이트에 많이 사용되는 패턴
+            - P2P 사이트(Peer-to-Peer): 사용자끼리 서로 직접 자료나 정보를 주고 받는 구조
+- Swagger란?
+
+  ### Swagger란?
+
+    - Swagger는 개발한 Rest API를 문서화 함
+    - 문서화된 내용을 통해 관리 & API 호출을 통한 테스트를 가능하게 함
+    - API Test 할 때 많이 사용되는 PostMan과 비슷
+
+  ### 왜 쓰는가?
+
+    - 백엔드에서 API를 만들면 아래와 같은 정보들이 필요.
+        - 주소가 어떤것인지
+        - GET인지 POST인지
+        - 어떤 값을 보내야 하는지
+        - 어떤 응답이 오는지
+        - 인증이 필요한지
+    - 위의 내용을 문서처럼 정리해서 보여주고, 심지어 직접 눌러서 테스트도 하게 해줌.
+- 도메인형 아키텍처란?
+
+  ### 도메인형 아키텍처란?
+
+    - 프로그램을 회원, 주문, 결제, 게시글처럼 기능(도메인)별로 나누는 구조
+
+    ```jsx
+    <계층형 구조>
+    - controller
+    - service
+    - repository
+    - domain
+
+    <도메인형 구조>
+    - member
+    	- MemberController
+    	- MemberService
+    	- MemberRepository
+    - order
+    	- OrderController
+    	- OrderService
+    	- OrderRepository
+    ```
+
+  ### 왜 쓰는가?
+
+    - 기능별로 코드 찾기가 쉬움
+    - 관련 코드가 한곳에 모여 있어서 관리가 편함
+    - 프로젝트가 커질수록 정리가 잘 됨
+- DDD vs 도메인형 아키텍처
+
+  ### DDD
+
+    - Domain-Driven Design
+    - 프로그램을 만들 때 업무 개념(도메인)을 중심으로 설계하자.
+    - DDD는 단순히 폴더 나누기가 아니라 “이 서비스의 핵심 업무가 뭐고, 그걸 코드에 어떻게 담을까?”를 고민하는 방식
+
+  ### 도메인형 아키텍처
+
+    - 도메인형 아키텍처는 코드를 member, order, payment 같은 기능별 폴더로 나누는 방식
+
+    ```jsx
+    member
+     ┣ MemberController
+     ┣ MemberService
+     ┣ MemberRepository
+
+    order
+     ┣ OrderController
+     ┣ OrderService
+     ┣ OrderRepository
+    ```
+
+    - 즉, 관련된 코드를 한 도메인 안에 묶는 패키지 구조에 가까움.
+- 왜 DTO를 사용하는가?
+
+  ### DTO란?
+
+    - 데이터를 전달하기 위한 객체 = 필요한 데이터만 담아서 보내는 상자
+
+  ### 왜 쓰는가?
+
+    1. **필요한 데이터만 보내기 위해**
+        - ex) <회원 엔티티>
+            - 아이디
+            - 비밀번호
+            - 이메일
+            - 주민번호
+        - 들어있다고 해도, 화면에 보낼 때는 이름이랑 이메일만 필요할 경우
+        - DTO를 쓰면 필요한 값만 담아서 보낼 수 있음
+    2. **엔티티를 그대로 노출하지 않기 위해**
+        - 엔티티는 보통 DB 테이블이랑 연결된 객체라서 그걸 그대로 밖에 내보내면 위험.
+        - ex)
+            - 비밀번호 같은 민감한 값이 노출될 수 있음
+            - 내부 구조가 외부에 그대로 드러남
+            - 엔티티 구조가 바뀌면 API도 같이 흔들림
+        - DTO를 쓰면 엔티티를 보호하면서 외부에 보여줄 데이터만 따로 관리할 수 있음
+    3. **계층 간 역할을 분리하기 위해**
+        - 컨트롤러, 서비스, 레포지토리 역할을 나눌 때 DTO를 쓰면 어떤 데이터를 주고 받는지 명확해짐
+        - ex)
+            - 요청용 DTO
+            - 응답용 DTO
+    4. **유지보수가 쉬워짐**
+        - 나중에 응답 형식을 바꿔야 할 때 엔티티를 직접 건드리지 않고 DTO만 수정할 수 있음.
+- 컨버터는 왜 사용하는가?
+
+  ### 컨버터란?
+
+    - 한 형태의 데이터를 다른 형태로 바꿔주는 것 = 변환기
+    - ex)
+        - 회원가입 요청 DTO → Member 엔티티
+        - Member 엔티티 → 회원 정보 응답 DTO
+        - 객체의 모양이 다를 때 바꿔주는 역할을 함
+
+  ### 왜 필요한가?
+
+    1. 객체마다 역할이 다르기 때문
+        - 프로그램에서는 다 같은 데이터처럼 보여도 역할이 다름
+            - DTO: 데이터 전달용
+            - Entity: DB 저장용
+        - 그래서 그대로 쓰지 않고, 상황에 맞는 형태로 바꿈.
+    2. 코드를 깔끔
+    3. 재사용
+    4. 수정 쉬움