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