SlideShare a Scribd company logo
1 of 19
Clean 아키텍처 재해석
빨리 가는 유일한 방법은 제대로 가는 것이다.
Robert C. Martin
좋은 아키텍처란
배포파일
배포 용이성
시스템 생명 주기(개발, 유지보수, 배포, 운영)를 쉽게 지원할 수 있는 아키텍처(모노리틱 지양/컴포넌트 단
위로 분리)
Gateway 서
버
Micro 서비스
Micro 서비스
운영비용 절감
개발 / 유지보수
용이성
설계원칙
단일 책임 원칙
A클래스 B클래스
A 기능만 제공
설계원칙
개방 폐쇄 원칙
부모 클래스
(고수준정책)
자식 클래스
(저수준정책)
확장에 열려 있음
변경에 닫혀 있음
설계원칙
A모듈
A클래스
B모듈
B클래스
치환 가능해야 함
리스코프 치환 원칙(LSP) : 대체 가능한 시스템을 만들기 위해 구성 요소간 치환 가능해야 함
설계원칙
A모듈
(불필요한 기능 포함)
B모듈
import
Software
C모듈
ISP 인터페이스 분리 원칙(ISP) : 불필요한 기능에 의존하지 말것
의존 X
의존 X
수정에 영향 X
부모 클래스
(고수준정책)
자식 클래스
(저수준정책)
의존 X
설계원칙
의존성 역전 원칙 : 고수준 정책 코드는 저수준 코드에 의존해서는 안됨
구현 클래스
(변동성 큰 구현체)
의존 X
(오버라이드 X)
자식 클래스
(하위 클래스)
안정된 추상화
의존성 역전 원칙(DIP)의 시스템은 추상 인터페이스/클래스에 의존한 유연성이 극대화된 시스템
추상 클래스 / 인터페이스
(변동성 큰 구현체)
의존 O
자식 클래스
(하위 클래스)
추상 클래스
컴포넌트 응집도 - 재사용/릴리즈 등가 원칙(Reuse/Release Equivalence Principle)
클래스A 클래스B
컴포넌트 A
컴포넌트(jar, dll 등)로 묶을때는 관련 클래스와 관련 모듈을 함께 묶어 릴리즈 함
Release 번호 부여
컴포넌트 응집도 - 공통 폐쇄 원칙(Common Closure Principle)
컴포넌트 A
(자주 변경)
컴포넌트 C
(자주 변경 X)
컴포넌트 B
(자주 변경)
컴포넌트 AB
자주 변경되는 컴포넌트는 묶어서 관리한다
컴포넌트 응집도 - 공통 재사용 원칙(Common Reuse Principle)
클래스 A
(자주 변경)
클래스 C
(자주 변경 X)
클래스 B
(자주 변경)
컴포넌트 A
묶어야할 컴포넌트, 묶으면 안되는 컴포넌트를 구분
컴포넌트 B
재사용 가능한 컴포넌트
일본어 날씨 UI
한국어 날씨 UI
한국어 날씨
Data
일본어 날씨
Data
날씨 매핑 Rule
API정의/ 재사용가
능
재사용 가능한 컴포넌트를 두어 확장 가능한 형태로 설계함
경계 : 선 긋기
Database Interface
Database Access Database
Business Rule / Logic
다른 DB로 교체 가능함
SQL 생성
DB 컨트롤 역할
< I >
관련된 것(의존성)과 관련 없는 것을 구분해 선을 그음
계층과 경계 : 마이크로서비스 아키텍처의 결합 상태
Micro 서버 Micro 서버
분리
DB
결합 결합
네트워크 공유 자
원
서버가 분리 되었더라도 네트워크 공유 자원이 있다면 결합 상태가 됨
계층과 경계 : 마이크로서비스 내에 횡단 관심사의 문제
A도시 버스
API
B도시 버스
API
버스 검색기
서버
정류소별 버스도착 시
간
횡단 관심 영역
횡단 관심 영역에 ‘버스 승차 정보’를 추가하려면 모든 API를 수정해야함
버스 승차 정보
계층과 경계 : 마이크로서비스 내에 횡단 관심사 문제 해결
A도시 버스
JAR
버스 검색기
서버
정류소별 버스도착 시
간
횡단 관심 영역
버스 승차 정보 반영시, 하위 API를 컴포넌트(jar, dll)로 대체하여 동적 로딩 방식으로 개별 배포
B도시 버스
JAR
버스
추상화 클래
스
버스 승차 정보
배포 후 동적로딩
테스트 고려한 설계
상용 서버에 상용 코드를 테스트 서버로 분리해, 상용 서버의 위험한 코드 탑재를 없앰
테스트 서버
(테스트코드
O)
테스트 클라
이언트
테스트 API
상용 서버
(테스트코드X)
상용 API 호출
사용자 클라
이언트
상용 API
코드 수정 후 영향 X
프레임워크와 아키텍처를 분리
Spring
Framework
아키텍처 경계
MySQL
신규 Framework or DB로 이관을 대비해 특정 DB나 특정 Framework에 의존되지 않도록 함
표준 라이브
러리
Core
Code
React
관심 없는
세부 사항
아키텍처
의존 X

More Related Content

Similar to 클린 아키텍처 재해석

AWS re:Invent 특집(2) – 서버리스(Serverless) 마이크로서비스를 위한 일곱 가지 모범 사례 (윤석찬)
AWS re:Invent 특집(2) – 서버리스(Serverless) 마이크로서비스를 위한 일곱 가지 모범 사례 (윤석찬)AWS re:Invent 특집(2) – 서버리스(Serverless) 마이크로서비스를 위한 일곱 가지 모범 사례 (윤석찬)
AWS re:Invent 특집(2) – 서버리스(Serverless) 마이크로서비스를 위한 일곱 가지 모범 사례 (윤석찬)Amazon Web Services Korea
 
Micro Service Architecture
Micro Service ArchitectureMicro Service Architecture
Micro Service ArchitectureHEECHEOL YANG
 
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...문기 박
 
MSA ( Microservices Architecture ) 발표 자료 다운로드
MSA ( Microservices Architecture ) 발표 자료 다운로드MSA ( Microservices Architecture ) 발표 자료 다운로드
MSA ( Microservices Architecture ) 발표 자료 다운로드Opennaru, inc.
 
Better Scalable Flexible Soa Platform 0.8.0
Better Scalable Flexible Soa Platform 0.8.0Better Scalable Flexible Soa Platform 0.8.0
Better Scalable Flexible Soa Platform 0.8.0Kidong Lee
 
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSA
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSA클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSA
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSAVMware Tanzu Korea
 
[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기
[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기
[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기Amazon Web Services Korea
 
Openshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud NativeOpenshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud Nativerockplace
 
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017Amazon Web Services Korea
 
Sumologic Kubernetes technical demo deck
Sumologic Kubernetes technical demo deck Sumologic Kubernetes technical demo deck
Sumologic Kubernetes technical demo deck Guenjun Yoo
 
Sumologic Kubernetes 라이브데모
Sumologic Kubernetes 라이브데모Sumologic Kubernetes 라이브데모
Sumologic Kubernetes 라이브데모Guenjun Yoo
 
Umc.Core Frameworks
Umc.Core FrameworksUmc.Core Frameworks
Umc.Core Frameworks준일 엄
 
Intro to hpe helion stackato_paa_s
Intro to hpe helion stackato_paa_sIntro to hpe helion stackato_paa_s
Intro to hpe helion stackato_paa_sSeong-Bok Lee
 
Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...
Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...
Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...Cloud-Barista Community
 
[OpenInfra Days Korea 2018] Day 2 - E6 - 마이크로서비스를 위한 Istio & Kubernetes [다운로드...
[OpenInfra Days Korea 2018] Day 2 - E6 - 마이크로서비스를 위한 Istio & Kubernetes [다운로드...[OpenInfra Days Korea 2018] Day 2 - E6 - 마이크로서비스를 위한 Istio & Kubernetes [다운로드...
[OpenInfra Days Korea 2018] Day 2 - E6 - 마이크로서비스를 위한 Istio & Kubernetes [다운로드...OpenStack Korea Community
 
오픈소스 소프트웨어 성능 최적화 보고서 6장
오픈소스 소프트웨어 성능 최적화 보고서 6장오픈소스 소프트웨어 성능 최적화 보고서 6장
오픈소스 소프트웨어 성능 최적화 보고서 6장JamGun
 
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015 AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015 Amazon Web Services Korea
 
Azure Databases for PostgreSQL MYSQL and MariaDB
Azure Databases for PostgreSQL MYSQL and MariaDBAzure Databases for PostgreSQL MYSQL and MariaDB
Azure Databases for PostgreSQL MYSQL and MariaDBrockplace
 

Similar to 클린 아키텍처 재해석 (20)

AWS re:Invent 특집(2) – 서버리스(Serverless) 마이크로서비스를 위한 일곱 가지 모범 사례 (윤석찬)
AWS re:Invent 특집(2) – 서버리스(Serverless) 마이크로서비스를 위한 일곱 가지 모범 사례 (윤석찬)AWS re:Invent 특집(2) – 서버리스(Serverless) 마이크로서비스를 위한 일곱 가지 모범 사례 (윤석찬)
AWS re:Invent 특집(2) – 서버리스(Serverless) 마이크로서비스를 위한 일곱 가지 모범 사례 (윤석찬)
 
Micro Service Architecture
Micro Service ArchitectureMicro Service Architecture
Micro Service Architecture
 
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
 
J2 Ee
J2 EeJ2 Ee
J2 Ee
 
MSA ( Microservices Architecture ) 발표 자료 다운로드
MSA ( Microservices Architecture ) 발표 자료 다운로드MSA ( Microservices Architecture ) 발표 자료 다운로드
MSA ( Microservices Architecture ) 발표 자료 다운로드
 
Better Scalable Flexible Soa Platform 0.8.0
Better Scalable Flexible Soa Platform 0.8.0Better Scalable Flexible Soa Platform 0.8.0
Better Scalable Flexible Soa Platform 0.8.0
 
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSA
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSA클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSA
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSA
 
[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기
[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기
[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기
 
Openshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud NativeOpenshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud Native
 
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
 
Sumologic Kubernetes technical demo deck
Sumologic Kubernetes technical demo deck Sumologic Kubernetes technical demo deck
Sumologic Kubernetes technical demo deck
 
Sumologic Kubernetes 라이브데모
Sumologic Kubernetes 라이브데모Sumologic Kubernetes 라이브데모
Sumologic Kubernetes 라이브데모
 
Umc.Core Frameworks
Umc.Core FrameworksUmc.Core Frameworks
Umc.Core Frameworks
 
Intro to hpe helion stackato_paa_s
Intro to hpe helion stackato_paa_sIntro to hpe helion stackato_paa_s
Intro to hpe helion stackato_paa_s
 
Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...
Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...
Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...
 
Sencha ExtJS를 활용한 Big Data Platform 개발 사례
Sencha ExtJS를 활용한 Big Data Platform 개발 사례 Sencha ExtJS를 활용한 Big Data Platform 개발 사례
Sencha ExtJS를 활용한 Big Data Platform 개발 사례
 
[OpenInfra Days Korea 2018] Day 2 - E6 - 마이크로서비스를 위한 Istio & Kubernetes [다운로드...
[OpenInfra Days Korea 2018] Day 2 - E6 - 마이크로서비스를 위한 Istio & Kubernetes [다운로드...[OpenInfra Days Korea 2018] Day 2 - E6 - 마이크로서비스를 위한 Istio & Kubernetes [다운로드...
[OpenInfra Days Korea 2018] Day 2 - E6 - 마이크로서비스를 위한 Istio & Kubernetes [다운로드...
 
오픈소스 소프트웨어 성능 최적화 보고서 6장
오픈소스 소프트웨어 성능 최적화 보고서 6장오픈소스 소프트웨어 성능 최적화 보고서 6장
오픈소스 소프트웨어 성능 최적화 보고서 6장
 
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015 AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
 
Azure Databases for PostgreSQL MYSQL and MariaDB
Azure Databases for PostgreSQL MYSQL and MariaDBAzure Databases for PostgreSQL MYSQL and MariaDB
Azure Databases for PostgreSQL MYSQL and MariaDB
 

More from Jin wook

자연어처리 소개
자연어처리 소개자연어처리 소개
자연어처리 소개Jin wook
 
Angular2를 위한 컴포넌트 분석과 개발
Angular2를 위한 컴포넌트 분석과 개발Angular2를 위한 컴포넌트 분석과 개발
Angular2를 위한 컴포넌트 분석과 개발Jin wook
 
Angular2를 위한 타입스크립트
Angular2를 위한 타입스크립트Angular2를 위한 타입스크립트
Angular2를 위한 타입스크립트Jin wook
 
Angular2를 활용한 컴포넌트 중심의 개발
Angular2를 활용한 컴포넌트 중심의 개발Angular2를 활용한 컴포넌트 중심의 개발
Angular2를 활용한 컴포넌트 중심의 개발Jin wook
 
MIPS CPU의 이해 (입문)
MIPS CPU의 이해 (입문)MIPS CPU의 이해 (입문)
MIPS CPU의 이해 (입문)Jin wook
 
Mongo DB 성능최적화 전략
Mongo DB 성능최적화 전략Mongo DB 성능최적화 전략
Mongo DB 성능최적화 전략Jin wook
 
PHP를 위한 NginX(엔진엑스) 시작과 설정
PHP를 위한 NginX(엔진엑스) 시작과 설정PHP를 위한 NginX(엔진엑스) 시작과 설정
PHP를 위한 NginX(엔진엑스) 시작과 설정Jin wook
 
Mongo DB로 진행하는 CRUD
Mongo DB로 진행하는 CRUDMongo DB로 진행하는 CRUD
Mongo DB로 진행하는 CRUDJin wook
 
아파치 쓰리프트 (Apache Thrift)
아파치 쓰리프트 (Apache Thrift) 아파치 쓰리프트 (Apache Thrift)
아파치 쓰리프트 (Apache Thrift) Jin wook
 
Node.js의 도입과 활용
Node.js의 도입과 활용Node.js의 도입과 활용
Node.js의 도입과 활용Jin wook
 
파이썬(Python) 소개
파이썬(Python) 소개파이썬(Python) 소개
파이썬(Python) 소개Jin wook
 
빅 데이터 개요 및 활용
빅 데이터 개요 및 활용빅 데이터 개요 및 활용
빅 데이터 개요 및 활용Jin wook
 
AngularJS의 개발방식에 대하여
AngularJS의 개발방식에 대하여AngularJS의 개발방식에 대하여
AngularJS의 개발방식에 대하여Jin wook
 

More from Jin wook (13)

자연어처리 소개
자연어처리 소개자연어처리 소개
자연어처리 소개
 
Angular2를 위한 컴포넌트 분석과 개발
Angular2를 위한 컴포넌트 분석과 개발Angular2를 위한 컴포넌트 분석과 개발
Angular2를 위한 컴포넌트 분석과 개발
 
Angular2를 위한 타입스크립트
Angular2를 위한 타입스크립트Angular2를 위한 타입스크립트
Angular2를 위한 타입스크립트
 
Angular2를 활용한 컴포넌트 중심의 개발
Angular2를 활용한 컴포넌트 중심의 개발Angular2를 활용한 컴포넌트 중심의 개발
Angular2를 활용한 컴포넌트 중심의 개발
 
MIPS CPU의 이해 (입문)
MIPS CPU의 이해 (입문)MIPS CPU의 이해 (입문)
MIPS CPU의 이해 (입문)
 
Mongo DB 성능최적화 전략
Mongo DB 성능최적화 전략Mongo DB 성능최적화 전략
Mongo DB 성능최적화 전략
 
PHP를 위한 NginX(엔진엑스) 시작과 설정
PHP를 위한 NginX(엔진엑스) 시작과 설정PHP를 위한 NginX(엔진엑스) 시작과 설정
PHP를 위한 NginX(엔진엑스) 시작과 설정
 
Mongo DB로 진행하는 CRUD
Mongo DB로 진행하는 CRUDMongo DB로 진행하는 CRUD
Mongo DB로 진행하는 CRUD
 
아파치 쓰리프트 (Apache Thrift)
아파치 쓰리프트 (Apache Thrift) 아파치 쓰리프트 (Apache Thrift)
아파치 쓰리프트 (Apache Thrift)
 
Node.js의 도입과 활용
Node.js의 도입과 활용Node.js의 도입과 활용
Node.js의 도입과 활용
 
파이썬(Python) 소개
파이썬(Python) 소개파이썬(Python) 소개
파이썬(Python) 소개
 
빅 데이터 개요 및 활용
빅 데이터 개요 및 활용빅 데이터 개요 및 활용
빅 데이터 개요 및 활용
 
AngularJS의 개발방식에 대하여
AngularJS의 개발방식에 대하여AngularJS의 개발방식에 대하여
AngularJS의 개발방식에 대하여
 

클린 아키텍처 재해석

  • 2. 빨리 가는 유일한 방법은 제대로 가는 것이다. Robert C. Martin
  • 3. 좋은 아키텍처란 배포파일 배포 용이성 시스템 생명 주기(개발, 유지보수, 배포, 운영)를 쉽게 지원할 수 있는 아키텍처(모노리틱 지양/컴포넌트 단 위로 분리) Gateway 서 버 Micro 서비스 Micro 서비스 운영비용 절감 개발 / 유지보수 용이성
  • 4. 설계원칙 단일 책임 원칙 A클래스 B클래스 A 기능만 제공
  • 5. 설계원칙 개방 폐쇄 원칙 부모 클래스 (고수준정책) 자식 클래스 (저수준정책) 확장에 열려 있음 변경에 닫혀 있음
  • 6. 설계원칙 A모듈 A클래스 B모듈 B클래스 치환 가능해야 함 리스코프 치환 원칙(LSP) : 대체 가능한 시스템을 만들기 위해 구성 요소간 치환 가능해야 함
  • 7. 설계원칙 A모듈 (불필요한 기능 포함) B모듈 import Software C모듈 ISP 인터페이스 분리 원칙(ISP) : 불필요한 기능에 의존하지 말것 의존 X 의존 X 수정에 영향 X
  • 8. 부모 클래스 (고수준정책) 자식 클래스 (저수준정책) 의존 X 설계원칙 의존성 역전 원칙 : 고수준 정책 코드는 저수준 코드에 의존해서는 안됨
  • 9. 구현 클래스 (변동성 큰 구현체) 의존 X (오버라이드 X) 자식 클래스 (하위 클래스) 안정된 추상화 의존성 역전 원칙(DIP)의 시스템은 추상 인터페이스/클래스에 의존한 유연성이 극대화된 시스템 추상 클래스 / 인터페이스 (변동성 큰 구현체) 의존 O 자식 클래스 (하위 클래스) 추상 클래스
  • 10. 컴포넌트 응집도 - 재사용/릴리즈 등가 원칙(Reuse/Release Equivalence Principle) 클래스A 클래스B 컴포넌트 A 컴포넌트(jar, dll 등)로 묶을때는 관련 클래스와 관련 모듈을 함께 묶어 릴리즈 함 Release 번호 부여
  • 11. 컴포넌트 응집도 - 공통 폐쇄 원칙(Common Closure Principle) 컴포넌트 A (자주 변경) 컴포넌트 C (자주 변경 X) 컴포넌트 B (자주 변경) 컴포넌트 AB 자주 변경되는 컴포넌트는 묶어서 관리한다
  • 12. 컴포넌트 응집도 - 공통 재사용 원칙(Common Reuse Principle) 클래스 A (자주 변경) 클래스 C (자주 변경 X) 클래스 B (자주 변경) 컴포넌트 A 묶어야할 컴포넌트, 묶으면 안되는 컴포넌트를 구분 컴포넌트 B
  • 13. 재사용 가능한 컴포넌트 일본어 날씨 UI 한국어 날씨 UI 한국어 날씨 Data 일본어 날씨 Data 날씨 매핑 Rule API정의/ 재사용가 능 재사용 가능한 컴포넌트를 두어 확장 가능한 형태로 설계함
  • 14. 경계 : 선 긋기 Database Interface Database Access Database Business Rule / Logic 다른 DB로 교체 가능함 SQL 생성 DB 컨트롤 역할 < I > 관련된 것(의존성)과 관련 없는 것을 구분해 선을 그음
  • 15. 계층과 경계 : 마이크로서비스 아키텍처의 결합 상태 Micro 서버 Micro 서버 분리 DB 결합 결합 네트워크 공유 자 원 서버가 분리 되었더라도 네트워크 공유 자원이 있다면 결합 상태가 됨
  • 16. 계층과 경계 : 마이크로서비스 내에 횡단 관심사의 문제 A도시 버스 API B도시 버스 API 버스 검색기 서버 정류소별 버스도착 시 간 횡단 관심 영역 횡단 관심 영역에 ‘버스 승차 정보’를 추가하려면 모든 API를 수정해야함 버스 승차 정보
  • 17. 계층과 경계 : 마이크로서비스 내에 횡단 관심사 문제 해결 A도시 버스 JAR 버스 검색기 서버 정류소별 버스도착 시 간 횡단 관심 영역 버스 승차 정보 반영시, 하위 API를 컴포넌트(jar, dll)로 대체하여 동적 로딩 방식으로 개별 배포 B도시 버스 JAR 버스 추상화 클래 스 버스 승차 정보 배포 후 동적로딩
  • 18. 테스트 고려한 설계 상용 서버에 상용 코드를 테스트 서버로 분리해, 상용 서버의 위험한 코드 탑재를 없앰 테스트 서버 (테스트코드 O) 테스트 클라 이언트 테스트 API 상용 서버 (테스트코드X) 상용 API 호출 사용자 클라 이언트 상용 API 코드 수정 후 영향 X
  • 19. 프레임워크와 아키텍처를 분리 Spring Framework 아키텍처 경계 MySQL 신규 Framework or DB로 이관을 대비해 특정 DB나 특정 Framework에 의존되지 않도록 함 표준 라이브 러리 Core Code React 관심 없는 세부 사항 아키텍처 의존 X

Editor's Notes

  1. 20p 관리자에게 아키텍처 중요성을 설득해야함. 아키텍처는 시스템이 제공하는 특성이나 기능보다 시스템의 구조에더 중점을 둔다.
  2. 10p 나쁜 아키텍처는 월 인건비가 증가하며, 생산성이 계속 해서 떨어진다. 62p 좋은 소프트웨어 시스템은 깔끔한 코드로 부터 시작한다.(clean code) 좋은 벽돌이 아니면 아무리 좋은 아키텍처라도 소용없다.
  3. 62p 좋은 소프트웨어 시스템은 깔끔한 코드로 부터 시작한다.(clean code) 좋은 벽돌이 아니면 아무리 좋은 아키텍처라도 소요없다.
  4. 62p 좋은 소프트웨어 시스템은 깔끔한 코드로 부터 시작한다.(clean code) 좋은 벽돌이 아니면 아무리 좋은 아키텍처라도 소요없다.
  5. 62p 좋은 소프트웨어 시스템은 깔끔한 코드로 부터 시작한다.(clean code) 좋은 벽돌이 아니면 아무리 좋은 아키텍처라도 소요없다.
  6. 변경 가능성이 높은 컴포넌트를 묶는다.
  7. 변경 가능성이 높은 컴포넌트를 묶는다.
  8. 변경 가능성이 높은 컴포넌트를 묶는다.
  9. 236p 날씨 매핑 Rule은 언어에 상관 없이 공통으로 재사용 가능하고, 언어에 따라 확장이 가능하다. 일본어 사용자에게는 일본어 날씨 UI가 제공되고, 한국어 사용자에게는 한국어 날씨 UI가 제공된다. 239p 재사용 가능한 컴포넌트에 대해서만 집중하면 다이어그램을 단순화 시킬 수 있다. (세로 선을 그엇다) 243p YAGNI (you aren’t going to neet it), 오버 엔지니어링이 언더 엔지니어링보다 나쁠 때가 훨씬 많다.
  10. 252p 분리 되어 배포 독립성을 보장한다. 그러나 네트워크 공유 자원이 있다면 결합될 가능성이 여전히 존재한다. 254p 독립적으로 개발하고 배포할 수 있는 구조가 아니다.
  11. 252p 횡단 관심사가 지닌 문제가 있다. 횡단 관심사 영역에 정류소별 버스도착 시간 외에, 정류소별 승차 인원 정보를 추가하려고 한다면 API를 모두 수정해야 할 것입니다.
  12. 256p 전략 패턴을 이용한다. jar 라는 방식을 이용하기 까지 50년이 걸렸다고 책에서 설명한다…
  13. 265p 테스트는 시스템의 일부이다. 테스트 API 자체를 분리하여 두면 위험한 구현부는 독립저윽로 배포할 수 있도록 컴포넌트를 분리한다.
  14. 209p 좋은 아키텍처는 레일스, 스프링, 하이버네이터, 톰캣, MytSQL에 대한 결정을 하지 않아도 되도록 해준다. 유스케이스를 중점으로 둔다. 214P : 프레임워크 독립성, 테스트 용이성 (UI없이도 테스트 가능), DB 독립성 MySQL을 몽고 DB등으로 교체할 수 있어야한다. 307; 프레임워크와의 첫만남부터 바로 결혼하려 들지 마라. 스프링의 @autowired를 쓰기보다, 메인 컴포넌트에에서 스프링을 사용해서 의존성을 주입하는 편이 낫다. 예외적으로 STL과 C++은 결혼할 가능성이 높다. 자바는 표준 라이브러리와는 결합해야한다. 306p : 프레임워크는 초기 기능을 만들기 위해서 필요하다. 그러나 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게될 가능성이있다. 328p 캡슐화 매커니즘을 고려해서, public이 적으면 의존성의 수도 줄어든다.