클린아키텍처와 DDD - day1
•
0 gefällt mir•198 views
응집도&결합도부터 중심으로 클린아키텍처(Clean Architecture) 1~4부를 설명합니다.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 클린아키텍처와 DDD - day1
Ähnlich wie 클린아키텍처와 DDD - day1 (20)
클린아키텍처와 DDD - day1
- 2. stein.park@kakao 구성 • 1. 바닥 다지기 : 클린 아키텍처 1부~4부 • 응집도가 높게 패키지 구성해보기 • 응집도&교착도, SOLID, 컴포넌트, dependency • 2. 아키텍처 : 클린 아키텍처 5부 • Domain 레이어가 분리되는 과정 이해하기 • 3-tier, MVC, service layer, domain layer • 클린 아키텍처 이해하기 • 3. Domain(layer) Driven Design : DDD Reference + DDD Distilled • 도메인 레이어를 분리하기 위해 알아야할 사항들
- 3. WHY?
- 4. stein.park@kakao 해결영역이아닌문제영역에집중! 고객 S/W Make Right Product Make Product Right https://productfolio.com/problem-space-vs-solution-space/ [dddd, p39]
- 5. stein.park@kakao 하지만현실은… “무엇이 좋은가?”보다 “구현 가능한가?”에 많은 시간을 쏟음 PostMeta 수집 규칙 을 바꾸려면 어떻게 해야하 지?? [dddd, p99] 잘 정의된 PostMeta 수집 규칙은 무엇일까?
- 7. stein.park@kakao Action Bounded Context Reaction Subdomain 그럴려면DDD뭐시기그러고… 근데 Domain Model은 뭐지?? Auth Bounded Context Reaction Aggregate <<Root>> Reaction <<ValueObject>> UserId <<Command>> ReactCommand <<ValueObject>> UserId <<Entity>> User [dddd, p109 재구성] token <<DomainEvent>> Reacted
- 10. stein.park 1.바닥다지기 클린 아키텍처의 기본 지식들
- 11. stein.park@kakao 주요출처 [asd] Agile Software Development, Principles, Patterns, and Practices, 2003 [sd] Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, 1979/2008 [ca] The Clean Architecture(2017)
- 12. stein.park@kakao 주요출처 [asd] Agile Software Development, Principles, Patterns, and Practices, 2003 [sd] Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, 1979/2008 [ca] The Clean Architecture(2017)
- 13. stein.park@kakao 개요 • 1부: (아키텍처) 소개 • 2부: 프로그래밍 패러다임 • 3부에 앞서: 결합도&응집도 • 3부: SOLID • 4부: 컴포넌트 원칙(REP, CCP, CRP, ADP, SDP, SAP)
- 14. stein.park@kakao 1부소개 • 1장 : 설계(design)과 아키텍처(architecture)란? • 고수준에서 저수준으로 향하는 의사결정의 연속이며, 서로 이어져 있음 • 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소하는 것 • 좋은 설계(TDD 등)를 갖추면 시작부터 끝까지 빠름 • 2장: 두 가지 가치에 대한 이야기 • 두 가지 가치 = 행위(behavior) + 구조(structure) • 아키텍처는 형태(행위, 요구사항, 기능)에 독립적이어야하고, 그럴수록 더 실용적 • 변경을 쉽게 하는 구조를 만드는 것이 중요
- 15. stein.park@kakao 1부소개 • 변경이 쉬운 구조를 만들면 • 저수준과 고수준을 분리하고 • 의존성을 역전시켜주면 • 고수준에서 저수준으로 의사결정할 수 있음 • 고수준은 저수준에 독립적으로 의사결정
- 16. stein.park@kakao 2부벽돌부터시작하기:프로그래밍패러다임 • 구조적 프로그래밍: 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. • 함수를 증명가능한 더 작은 단위로 분해 & 테스트 • 테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다. - 다익스트라 • 객체 지향 프로그래밍: 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. • 캡슐화에는 딱히 강하지 않고, 상속에는 편리함을 주며, 다형성에는 안전&편리를 제공 • 다형성으로 의존성 역전이 쉬움 => 컴포넌트 분리가 쉬워짐 => 설계 자유도 UP • 함수형 프로그래밍: 할당문에 대한 규칙을 부과한다. • 경합조건, 교착상태, 동시 업데이트 모두 가변상태 때문인데 FP에서는 이 문제가 줄어듦 • 이벤트 소싱으로 데이터를 관리함으로써 완전한 불변성을 가질 수도 있음. 예) git 패러다임은 ‘해서는 안되는 것’을 규정
- 17. stein.park@kakao 2부벽돌부터시작하기:프로그래밍패러다임 • 구조적 프로그래밍: 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. • 함수를 증명가능한 더 작은 단위로 분해 & 테스트 • 테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다. - 다익스트라 • 객체 지향 프로그래밍: 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. • 캡슐화에는 딱히 강하지 않고, 상속에는 편리함을 주며, 다형성에는 안전&편리를 제공 • 다형성으로 의존성 역전이 쉬움 => 컴포넌트 분리가 쉬워짐 => 설계 자유도 UP • 함수형 프로그래밍: 할당문에 대한 규칙을 부과한다. • 경합조건, 교착상태, 동시 업데이트 모두 가변상태 때문인데 FP에서는 이 문제가 줄어듦 • 이벤트 소싱으로 데이터를 관리함으로써 완전한 불변성을 가질 수도 있음. 예) git 패러다임은 ‘해서는 안되는 것’을 규정 goto 쓰지마
- 18. stein.park@kakao 2부벽돌부터시작하기:프로그래밍패러다임 • 구조적 프로그래밍: 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. • 함수를 증명가능한 더 작은 단위로 분해 & 테스트 • 테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다. - 다익스트라 • 객체 지향 프로그래밍: 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. • 캡슐화에는 딱히 강하지 않고, 상속에는 편리함을 주며, 다형성에는 안전&편리를 제공 • 다형성으로 의존성 역전이 쉬움 => 컴포넌트 분리가 쉬워짐 => 설계 자유도 UP • 함수형 프로그래밍: 할당문에 대한 규칙을 부과한다. • 경합조건, 교착상태, 동시 업데이트 모두 가변상태 때문인데 FP에서는 이 문제가 줄어듦 • 이벤트 소싱으로 데이터를 관리함으로써 완전한 불변성을 가질 수도 있음. 예) git 패러다임은 ‘해서는 안되는 것’을 규정 goto 쓰지마 상속된 것으로만 전환해
- 19. stein.park@kakao 2부벽돌부터시작하기:프로그래밍패러다임 • 구조적 프로그래밍: 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. • 함수를 증명가능한 더 작은 단위로 분해 & 테스트 • 테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다. - 다익스트라 • 객체 지향 프로그래밍: 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. • 캡슐화에는 딱히 강하지 않고, 상속에는 편리함을 주며, 다형성에는 안전&편리를 제공 • 다형성으로 의존성 역전이 쉬움 => 컴포넌트 분리가 쉬워짐 => 설계 자유도 UP • 함수형 프로그래밍: 할당문에 대한 규칙을 부과한다. • 경합조건, 교착상태, 동시 업데이트 모두 가변상태 때문인데 FP에서는 이 문제가 줄어듦 • 이벤트 소싱으로 데이터를 관리함으로써 완전한 불변성을 가질 수도 있음. 예) git 패러다임은 ‘해서는 안되는 것’을 규정 goto 쓰지마 상속된 것으로만 전환해 immutable 만세
- 20. stein.park@kakao 3부에앞서:결합도&응집도 모듈: expression, statement, function, procedure, method, class, … ‘aggregate identifier’ [Structured Design, 1978, 2008] Kent Beck - youtube Stackoverflow - What does 'low in coupling and high in cohesion' mean Coursera - 객체 지향 설계 단일 액터를 책임지는 코드 를 함께 묶어주는 힘 - [ca] slide: CSC407-Structured Design by Dave A. Penny
- 21. stein.park@kakao 3부에앞서:결합도&응집도 모듈: expression, statement, function, procedure, method, class, … ‘aggregate identifier’ [Structured Design, 1978, 2008] Kent Beck - youtube Stackoverflow - What does 'low in coupling and high in cohesion' mean Coursera - 객체 지향 설계 모든 코드를 한 파일에 때려넣음 단일 액터를 책임지는 코드 를 함께 묶어주는 힘 - [ca] slide: CSC407-Structured Design by Dave A. Penny
- 22. stein.park@kakao 3부에앞서:결합도&응집도 모듈: expression, statement, function, procedure, method, class, … ‘aggregate identifier’ [Structured Design, 1978, 2008] Kent Beck - youtube Stackoverflow - What does 'low in coupling and high in cohesion' mean Coursera - 객체 지향 설계 모든 코드를 한 파일에 때려넣음 단일 액터를 책임지는 코드 를 함께 묶어주는 힘 - [ca] 응집도를 높이고 결합도를 줄여서 최적점을 찾자! slide: CSC407-Structured Design by Dave A. Penny
- 23. stein.park@kakao 결합도&응집도… 복잡하면 비용 증가 -> 나누자 -> 고려사항이 는다 -> 나눠도 비용증가??? 고려사항이 많아지면 복잡도가 증가 고려사항을 줄이기 위해 문제를 나눴더니 작아진 조각들 간에 복잡도가 증가 막 나누면 안되고 결합도를 낮추고 응집도를 높여라
- 25. stein.park@kakao Cohesion 응집도는 문제영역에서 찾는다! https://productfolio.com/problem-space-vs-solution-space/ 고객 S/W [dddd, p39] Make Right Product Make Product Right (s) (s)
- 27. stein.park@kakao 정리하자면…문제영역중심으로잘쪼개자 어떻게 해야 잘 쪼개는지는 뒤에서 다룸
- 28. stein.park@kakao 정리하자면…문제영역중심으로잘쪼개자 어떻게 해야 잘 쪼개는지는 뒤에서 다룸
- 30. stein.park@kakao Module,Component 응집도를 높이고 결합도를 줄이기 위한 원칙들 SRP = 단일책임원칙 OCP = 개방-폐쇄 원칙 LSP = 리스코프의 치환 원칙 ISP = 인터페이스 분리 원칙 DIP = 의존성 역전 원칙 모듈(+컴포넌트) = SOLID <응집도> REP = 재사용/릴리스 등가 원칙 CCP = 공통 폐쇄 원칙 CRP = 공통 재사용 원칙 <결합도> ADP = 의존성 비순환 원칙 하향식(top-down) 설계(불가원칙) SDP = 안정된 의존성 원칙 SAP = 안정된 추상화 원칙 https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html Design Principles and Design Patterns, Robert C. Martin, 2000 [ca][asd] [asd] https://sungjk.github.io/2019/10/26/clean-architecture-1.html [ca] 3부: 설계 원칙 4부: 컴포넌트 원칙
- 31. stein.park@kakao SRP=단일책임원칙 하나의 모듈은 하나의 액터에 대해서만 책임진다 ~= 잘게 잘 쪼갠다
- 32. stein.park@kakao SRP=단일책임원칙 하나의 모듈은 하나의 액터에 대해서만 책임진다 ~= 잘게 잘 쪼갠다
- 33. stein.park@kakao SRP=단일책임원칙 하나의 모듈은 하나의 액터에 대해서만 책임진다 ~= 잘게 잘 쪼갠다
- 34. stein.park@kakao SRP=단일책임원칙 하나의 모듈은 하나의 액터에 대해서만 책임진다 ~= 잘게 잘 쪼갠다
- 35. stein.park@kakao OCP=개방-폐쇄원칙 A가 B를 확장하는 것은 열려있지만, 변경하는 것은 닫혀있다. 재무 데이터 재무 분석기 보고서용 재무 데이터 보고서를 웹에 표시 보고서를 프린터로 출력 PM 관점에서 [oosc, §3.3] [oosc] https://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%20Software%20Construction.pdf 설명을 위해 화살표 방향을 바꿈 책에는 “데이터 흐름” 방향인데, “의존성 방향”으로 바꿈
- 36. stein.park@kakao OCP=개방-폐쇄원칙 A가 B를 확장하는 것은 열려있지만, 변경하는 것은 닫혀있다. 재무 데이터 재무 분석기 보고서용 재무 데이터 보고서를 웹에 표시 Open Open PM 관점에서 [oosc, §3.3] [oosc] https://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%20Software%20Construction.pdf 설명을 위해 화살표 방향을 바꿈 책에는 “데이터 흐름” 방향인데, “의존성 방향”으로 바꿈
- 37. stein.park@kakao OCP=개방-폐쇄원칙 A가 B를 확장하는 것은 열려있지만, 변경하는 것은 닫혀있다. 재무 데이터 재무 분석기 보고서용 재무 데이터 보고서를 웹에 표시 Close Close PM 관점에서 [oosc, §3.3] [oosc] https://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%20Software%20Construction.pdf 설명을 위해 화살표 방향을 바꿈 책에는 “데이터 흐름” 방향인데, “의존성 방향”으로 바꿈
- 38. stein.park@kakao OCP=개방-폐쇄원칙 A가 B를 확장하는 것은 열려있지만, 변경하는 것은 닫혀있다. 재무 데이터 재무 분석기 보고서용 재무 데이터 보고서를 웹에 표시 보고서를 프린터로 출력 Open Close Close PM 관점에서 [oosc, §3.3] [oosc] https://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%20Software%20Construction.pdf 설명을 위해 화살표 방향을 바꿈 책에는 “데이터 흐름” 방향인데, “의존성 방향”으로 바꿈
- 39. stein.park@kakao OCP=개방-폐쇄원칙 A가 B를 확장하는 것은 열려있지만, 변경하는 것은 닫혀있다. 재무 데이터 재무 분석기 보고서용 재무 데이터 보고서를 웹에 표시 보고서를 프린터로 출력 Open Close Reopen PM 관점에서 [oosc, §3.3] [oosc] https://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%20Software%20Construction.pdf 설명을 위해 화살표 방향을 바꿈 책에는 “데이터 흐름” 방향인데, “의존성 방향”으로 바꿈 유형 별 enum
- 40. stein.park@kakao OCP=개방-폐쇄원칙 A가 B를 확장하는 것은 열려있지만, 변경하는 것은 닫혀있다. 재무 데이터 재무 분석기 보고서용 재무 데이터 보고서를 웹에 표시 보고서를 프린터로 출력 Open Close Reopen Reopen PM 관점에서 [oosc, §3.3] [oosc] https://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%20Software%20Construction.pdf 설명을 위해 화살표 방향을 바꿈 책에는 “데이터 흐름” 방향인데, “의존성 방향”으로 바꿈 유형 별 enum
- 41. stein.park@kakao OCP=개방-폐쇄원칙 A가 B를 확장하는 것은 열려있지만, 변경하는 것은 닫혀있다. 재무 데이터 재무 분석기 보고서용 재무 데이터 보고서를 웹에 표시 보고서를 프린터로 출력 Open Close Reopen Reopen Reopen PM 관점에서 [oosc, §3.3] [oosc] https://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%20Software%20Construction.pdf 설명을 위해 화살표 방향을 바꿈 책에는 “데이터 흐름” 방향인데, “의존성 방향”으로 바꿈 유형 별 enum
- 42. stein.park@kakao OCP=개방-폐쇄원칙 고수준이 Closed 될 수 있도록 저수준 -> 고수준으로 의존성을 역전 재무 데이터 재무 분석기 보고서용 재무 데이터 웹에 표시 프린터로 출력
- 46. stein.park@kakao OCP=개방-폐쇄원칙 추이 종속성(transitive dependency) Controller가 entities의 getter/setter를 이용해 뭔가 로직을 수행하면 entities가 수정될 때 controller도 체크해 봐야함.
- 47. stein.park@kakao OCP=개방-폐쇄원칙 추이 종속성(transitive dependency) Controller가 entities의 getter/setter를 이용해 뭔가 로직을 수행하면 entities가 수정될 때 controller도 체크해 봐야함.
- 48. stein.park@kakao OCP=개방-폐쇄원칙 추이 종속성(transitive dependency) Controller가 entities의 getter/setter를 이용해 뭔가 로직을 수행하면 entities가 수정될 때 controller도 체크해 봐야함.
- 49. stein.park@kakao LSP=리스코프의치환원칙 A를 사용하는 P에서 A를 B로 치환해도 P의 행위가 변하지 않으면 B는 A의 하위타입이다. Billing License + calcFee() Personal License Business License - users <I> User Rectangle + setH, + setW Square + setSide
- 50. stein.park@kakao Square + setSide OCP+LSP동시위반사례 Class User { void DrawShape(Shape s) { if (s instanceof Square) … else … } } User Rectangle + setH, + setW Interface가 아닌 구현 클래스 를 알아야하므로 LSP 위반 Rectangle의 기능을 확장하는데 User가 변경 되는 문제가 발생했으므로 OCP 위반 [asp, p133]
- 51. stein.park@kakao OCP+LSP동시위반사례 Class User { void DrawShape(Shape s) { if (s instanceof Square) … else … } } User Rectangle + setH, + setW Interface가 아닌 구현 클래스 를 알아야하므로 LSP 위반 Rectangle의 기능을 확장하는데 User가 변경 되는 문제가 발생했으므로 OCP 위반 [asp, p133] Open Open
- 52. stein.park@kakao OCP+LSP동시위반사례 Class User { void DrawShape(Shape s) { if (s instanceof Square) … else … } } User Rectangle + setH, + setW Interface가 아닌 구현 클래스 를 알아야하므로 LSP 위반 Rectangle의 기능을 확장하는데 User가 변경 되는 문제가 발생했으므로 OCP 위반 [asp, p133] Close Close
- 53. stein.park@kakao Square + setSide OCP+LSP동시위반사례 Class User { void DrawShape(Shape s) { if (s instanceof Square) … else … } } User Rectangle + setH, + setW Interface가 아닌 구현 클래스 를 알아야하므로 LSP 위반 Rectangle의 기능을 확장하는데 User가 변경 되는 문제가 발생했으므로 OCP 위반 [asp, p133] Close Close Open
- 54. stein.park@kakao Square + setSide OCP+LSP동시위반사례 Class User { void DrawShape(Shape s) { if (s instanceof Square) … else … } } User Rectangle + setH, + setW Interface가 아닌 구현 클래스 를 알아야하므로 LSP 위반 Rectangle의 기능을 확장하는데 User가 변경 되는 문제가 발생했으므로 OCP 위반 [asp, p133] Reopen Close Open
- 55. stein.park@kakao ISP=인터페이스분리원칙 필요한 것에만 의존성을 갖기위해 인터페이스를 작게 유지한다.
- 56. stein.park@kakao ISP=인터페이스분리원칙 필요한 것에만 의존성을 갖기위해 인터페이스를 작게 유지한다. 필요 이상으로 많은 것을 포함하는 모듈에 의존하는 것은 해로운 일 고려사항이 는다 = 에러가 는다
- 57. stein.park@kakao DIP=의존성역전원칙 고수준 정책을 구현하는 코드는 저수준 세부사항 코드에 의존하면 안 된다. 대신 세부사항이 정책에 의존해야 한다. a. 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안된다. 둘 모두 추상화에 의존해야한다. b. 추상화는 구체적인 사항에 의존해서는 안 된다. 구체적인 사항은 추상화에 의존해야 한다. [asd] DIP 예외 User가 Square 때문에 Open되는 문제 해결 의존성(dependency) 방향이 제어흐름 의 정반대 방향으로 역전(inversion) (more…)
- 58. stein.park@kakao Dependencyvsflowofcontrol Dependency 소스 코드 의존성은 반드 시 안쪽으로, 고수준의 정책을 향해야 한다. Flow of control 실행 순서 https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- 59. stein.park@kakao 응집도:REP,CCP,CRP REP Group for reusers CCP Group for maintenance CRP Split to avoid unneeded releases 재사용/릴리스(번호) 등가 원칙 공통 재사용 원칙 (= 컴포넌트의 ISP) 공통 폐쇄 원칙 (= 컴포넌트의 SRP)
- 60. stein.park@kakao ADP:특징 main은 언제든지 배포가능 Test에 걸리적거리 지 않음 여기서부터 차례대 로 릴리즈하면 됨
- 65. stein.park@kakao 하향식(top-down)설계 모듈을 하나씩 만들어감 의존성이 쌓이면서 SRP/CCP로 컴포넌트 묶음 너무 커진 컴포넌트를 CRP로 분리 그 과정에 순환이 발생하면 ADP 적용
- 66. stein.park@kakao 변경 후 변경 전 결합도:SDP+SAP=DIP Stable U UServer US Flexible C Stable U Flexible C [s]
- 67. stein.park@kakao 변경 후 변경 전 결합도:SDP+SAP=DIP Stable U UServer US Flexible C Stable U Flexible C GW 서버 [s]
- 69. stein.park@kakao 결합도:SDP+SAP https://uchanlee.dev/clean-architecture/book/ch14/ DB 스키마 (Bad) String (Good) I = Fan-out / (Fan-in + Fan-out) A = #(추상+인터페이스) / #클래스 D’ = 주계열과의 거리의 normalize 값 slf4j 삭제 하다 남은 Repo interface Logback
- 70. stein.park@kakao 정리하면… • 응집도 & 결합도 개념과 inter-module vs intra-module complexity • 응집도는 문제영역에서 찾기 • 컴포넌트는 모듈의 묶음이면서 배포단위 • Java의 패키지도 컴포넌트이고, Clean시스템도 컴포넌트 • S(잘게 쪼게고)O(Reopen 안되게하고)L(상속 제대로하고)I(인터페이스도 쪼게고)D(의 존성 역전으로 유연성 주고) • 컴포넌트 응집도: REP 지키면서, CCP로 묶고, CRP로 나누기 • 컴포넌트 결합도: 순환은 끊고(ADP), 안정성(SDP)과 추상도(SAP)에 따라 의존성 관리