Architecture chronicle - Speaker Deck

Architecture chronicle

by Buzzvil

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Copyright ⓒ All Right Reserved by Buzzvil Some architectural styles are often portrayed as ‘silver bullet’ solutions for all forms of software. However, a good designer should select a style that matches the needs of the particular problem being solved. Roy Fielding, 2000 No Silver Bullet Software Architecture Premises

Slide 15

Slide 15 text

Copyright ⓒ All Right Reserved by Buzzvil Terminology Software Architecture Premises Functional > related to technology - Layer - Factory - Repository - View - ViewModel Conceptual > related to domain - User - Product - Stock Management

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Copyright ⓒ All Right Reserved by Buzzvil Terminology Software Architecture Premises Architecture > technical decisions - 모든 기능 개발에 cross-cutting하는 기술적 결정 - 프레임워크, 코딩 표준, 문서화, 프로세스 등 - 프로젝트 후반에 바꾸기 어려운 기술적 결정 - 시스템의 큰 그림이며, 컴포넌트들과 그들의 관계 - 결정을 최대한 미루어 변화에 유연하게 만드는 것 - 컴포넌트와 모듈을 재사용 할 수 있게 만드는 것 - 코딩 표준, 개발 단계, CI/CD, 배포 등과 같은 표준을 만드는 것 - 한 사람이 결정하는 것이 아닌, 여러 팀의 숙련된 개발자 길드가 결정 ** 길드 - Spotify Engineering Culture Video Architect - 아키텍처의 수호자 / 촉진자 - 가장 숙련된 개발자로 큰 그림 상의 문제를 분석하고 해결하는데 더 “많은 책임" - 아키텍처와 관련된 사안을 결정할 때, 강력한 투표권 - 모든 개발자는 어느 시점이 되면 아키텍트가 되는데, 그때 아키텍처에 대해 제대로 이해 필요 - 숙련된 개발자는 어떤 방식으로든 아키텍처에 기여하기 때문에, 아키텍처 관리에 책임을 가짐 - 안티패턴 : 상아탑(Ivory Tower) 아키텍트 - 모든 것을 독단적으로 결정하는 아키텍트 Software Architecture […] is the set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both. Clements et al, 2010

Slide 19

Slide 19 text

Copyright ⓒ All Right Reserved by Buzzvil Terminology Software Architecture Premises Architecture Smell - Rigidity - Fragility - Immobility - Viscosity & System-wide Viscosity - Needless Repetition - Opacity - Needless Complexity

Slide 20

Slide 20 text

Copyright ⓒ All Right Reserved by Buzzvil Application Layer, High-level Module, Relations between modules - Component-based - Monolithic application - Layered - Pipes and ﬁlters - Event-driven - Publish-subscribe - Plugins - Client-server - Service-oriented Architecture Style ( = interface ) Architectural Style vs. Architectural Patterns vs. Design Patterns

Slide 21

Slide 21 text

Copyright ⓒ All Right Reserved by Buzzvil Pattern = Solution for repetitive problem Architecture Pattern = Solution for repetitive problem of architecture style Affect overall code base - Three-tier - Microkernel - Model-View-Controller - Model-View-ViewModel Architecture Pattern ( = implementation ) Architectural Style vs. Architectural Patterns vs. Design Patterns

Slide 22

Slide 22 text

Copyright ⓒ All Right Reserved by Buzzvil Architecture Pattern : codebase scope Design Pattern : localized scope - Factory Pattern - Strategy Pattern Design Pattern Architectural Style vs. Architectural Patterns vs. Design Patterns

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright ⓒ All Right Reserved by Buzzvil Monolithic Architecture When do we need to change from monolithic architecture to another? - 다른 도메인에 대한 독립적인 확장 - 컴포넌트나 모듈을 다른 프로그래밍 언어로 작성 - 배포 독립성 Anti-pattern : Spaghetti Architecture - 패키지 구조와 관계가 명확하지 않음 - 의존성에 규칙이 없음 - 변화와 리팩토링이 어려움 - 고장나기 쉬움 - 요약하자면 정리가 안 된 코드

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Copyright ⓒ All Right Reserved by Buzzvil Layered Architecture Layered Architecture In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behaviour of UI widgets and database scripts. This happens because it is the easiest way to make things work, in the short run. When the domain-related code is diffused through such a large amount of other code, it becomes extremely difficult to see and to reason about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. Automated testing is awkward. With all the technologies and logic involved in each activity, a program must be kept very simple or it becomes impossible to understand. Eric Evans 2014, Domain-Driven Design Reference Sometimes the layers are arranged so that the domain layer completely hides the data source from the presentation. More often, however, the presentation accesses the data store directly. While this is less pure, it tends to work better in practice. Fowler 2002, Patterns of Enterprise Application Architecture

Slide 31

Slide 31 text

Copyright ⓒ All Right Reserved by Buzzvil Anti-pattern: Lasagna Architecture Layered Architecture - 엄격하게 준수하면, 쓸데없는 프록시 클래스, 메소드 발생 - 과도하게 추상화를 하게 됨 - 작은 변경을 하기 위해서 어플리케이션 전체를 건드려야함 - 많은 계층을 만들면서 시스템 복잡도가 커지고 성능 저하 - functional하게 레이어를 나누기 때문에, conceptual한 개념이 파

Slide 32

Slide 32 text

Copyright ⓒ All Right Reserved by Buzzvil 1979 - Model-View-Controller Trygve Reenskaug MVC and its alternatives M : 비즈니스 로직 모델 (단일 객체 or 객체 구조) V : UI 위젯 (버튼, 텍스트 박스 등) C : View와 Model 사이를 조율 -> 어떤 데이터로 무엇을 보여줄지 -> 유저 액션을 비즈니스 로직으로 변환 1. View는 Model에 직접 접근하여 데이터르 보여준다. 2. Model 데이터가 변하면, 뷰를 바로 업데이트하는 이벤트를 트리거한다. (이 때 HTTP가 없었다) 3. 각 View는 하나의 Controller와 연관된다. 4. 각 스크린은 여러 View&Controller 쌍을 포함한다. 5. 각 Controller는 여러 View를 가질 수 있다.

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright ⓒ All Right Reserved by Buzzvil 1996 - Model-View-Presenter MVC and its alternatives - View는 수동적이면서, Model을 모른다 - Controller는 최대한 얇게 만들어서, 단순히 Command를 호출하고, 모델을 쿼리하고 View에 데이터를 전달한다. - 데이터의 변경은 View를 직접 갱신하지 않고, 항상 Presenter를 통해 전달한다. 이는 Presenter가 View를 갱신하기 전에 추가 로직을 수행할 수 있게 만든다. 예를 들면 변경된 데이터를 가져온다. - 각 View는 하나의 Presenter를 갖는다.

Slide 35

Slide 35 text

Copyright ⓒ All Right Reserved by Buzzvil 2005 - Model-View-ViewModel MVC and its alternatives - 하나의 ViewModel은 하나의 View와 일대일 대응이다. - View 로직은 ViewModel로 옮긴다. - View와 Model을 묶어서, ViewModel의 데이터가 변하면 View에 반영되도록 한다.

Slide 36

Slide 36 text

Copyright ⓒ All Right Reserved by Buzzvil Model-View-Presenter-ViewModel MVC and its alternatives 이런 것도 있음 <결론> - MVC와 그 파생 패턴들은 Rich Client인 프론트엔드에 유용 - Request/Response 패러다임에 맞지는 않음 - 대부분의 경우 MVC라고 쓰고 있는 것들은 MVP임 - 중요한 점은 각 패턴에 대해 이해하고, 적절한 것을 사용하는 것임 - 이런 패턴의 목적은 “low coupling”, “high cohesion”, “separation of concern”임

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Copyright ⓒ All Right Reserved by Buzzvil [1992] EBI Architecture Entity - = Entity in DDD / Clean Architecture Entity-Boundary-Interactor Beginners may sometime only use entity object as data carriers and place all dynamic behaviour in control objects […]. This should, however be avoided. […] Instead, quite a lot of behaviour should be placed in the entity objects. Ivar Jacobson 1992, pp. 134 Anemic Domain Model

Slide 39

Slide 39 text

Copyright ⓒ All Right Reserved by Buzzvil [1992] EBI Architecture Boundary - 시스템 인터페이스를 모델링 - 시스템 환경에 의존적인 모든 기능 - tools and delivery mechanism […] everything concerning the interface of the system is placed in an interface object Ivar Jacobson 1992, pp. 134 Anemic Domain Model

Slide 40

Slide 40 text

Copyright ⓒ All Right Reserved by Buzzvil Interactor [1992] EBI Architecture Behaviour that remains after the Interface objects and Entity objects have obtained their parts will be placed in the control objects Ivar Jacobson 1992, pp. 185 Boundary = View + Controller in MVC = Presentation Layer Entity = Model in MVC Interactor = Presentation Layer와 Entity 사이를 연결 = Application/Domain Service in DDD EBI for back-end MVC for front-end 하나의 패턴으로 조합하면 View-Controller-Interactor-Entity

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Copyright ⓒ All Right Reserved by Buzzvil [2005] Ports & Adapter Architecture (aka Hexagonal Architecture) Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases. Alistair Cockburn 2005, Ports and Adapters

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Copyright ⓒ All Right Reserved by Buzzvil [2005] Ports & Adapter Architecture (aka Hexagonal Architecture) 첫째, 인터페이스를 활용해서 어플리케이션을 외부로부터 분리한다. 둘째, UI는 어플리케이션 인터페이스를 사용하는 어댑터를 만든다. 셋째, 인프라는 어플리케이션 인터페이스를 구현하는 어댑터를 만든다.

Slide 49

Slide 49 text

Copyright ⓒ All Right Reserved by Buzzvil [2008] Onion Architecture Key tenets of Onion Architecture: - The application is built around an independent object model - Inner layers define interfaces. Outer layers implement interfaces - Direction of coupling is toward the center - All application core code can be compiled and run separate from infrastructure Jeffrey Palermo 2008, The Onion Architecture: part 3 […] the layers above can use any layer beneath them, not just the layer immediately beneath. Jeffrey Palermo 2008, The Onion Architecture: part 3

Slide 50

Slide 50 text

Copyright ⓒ All Right Reserved by Buzzvil 관리 가능한 코드 베이스 = 최소한의 코드 변경으로 기능 개발을 할 수 있는코드 장점 - 적은 코드에 영향을 주기 때문에 변경이 간단 - 적은 코드를 변경하기 때문에 빠름 - 적은 코드를 변경하기 때문에 버그가 적음 이를 위한 핵심 원칙 - 캡슐화 - 디커플링 - 응집도 Maintainable Codebase [2011] Screaming Architecture

Slide 51

Slide 51 text

Copyright ⓒ All Right Reserved by Buzzvil Encapsulation 의미 > 클래스 내부를 최대한 감추는 것 장점 > 구현을 숨기게 되면, 이 클래스를 사용하는 클래스들에 영향을 주지 않으면서 변경 가능 [2011] Screaming Architecture Low coupling 의미 > 커플링은 코드가 다른 코드와 연관된다는 의미 > 하나의 모듈 변경이 다른 모듈의 변경을 초래한다면 커플링 > 하나의 모듈 변경이 다른 모듈에 영향을 적기 준다면, low coupling > 캡슐화를 통해서 달성 장점 > maintainability - 변경은 하나의 모듈에만 영향 > testability - 유닛 테스트에 연관되는 모듈이 최소화 > readability - 분석해야하는 클래스가 최소화 High cohesion 의미 > 모듈의 함수들이 얼마나 강하게 연관되어 있는지 > 응집도가 낮으면 서로 연관없는 코드가 모인 것 장점 > readability - 긴밀하게 연관되어 있는 함수들은 하나의 모듈에 포함 > maintainability - 디버깅은 대부분 하나의 모듈에서 이루어짐 > reusability - 응집된 모듈은 쓸모없는 함수가 적음

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Copyright ⓒ All Right Reserved by Buzzvil [2011] Screaming Architecture Package by Layer - Module - Functional Package Package by Feature - Component - Conceptual Package V.S. Definition of Package By grouping classes into packages we can reason about the design at a higher level of abstraction. The goal is to partition the classes in your application according to some criteria, and then allocate those partitions to packages. The relationships between those packages expresses the high level organization of the application. Robert C. Martin 1996, Granularity pp. 3

Slide 54

Slide 54 text

Copyright ⓒ All Right Reserved by Buzzvil [2011] Screaming Architecture Package Cohesion Principles: - REP - The Release Reuse Equivalency Principle - The granule of reuse is the granule of release - CCP - The Common Closure Principle - Classes that change together are packaged together - CRP - The Common Reuse Principle - Classes that are used together are packaged together Package Coupling Principle - ADP - The Acyclic Dependencies Principle - The dependency graph of packages must have no cycles - SDP - The Stable Dependencies Principle - Depend in the direction of stability - SAP - The Stable Abstraction Principle - Abstractness increases with stability To design well decoupled components, it helps to reflect about: “if I would want to remove this business concept, by deleting its component root folder would all of the business concept code be removed and would the remaining application not break?” If the answer is yes, then we have a well decoupled component. 모든 코드 유닛은 논리적 경로가 유일해야 한다. 신입이나, 주니어 개발자가에게도 명확해야 한다. 만약 우리가 코드가 어디에 존재해야하는지 모르기 때문에 검색해야 한다면, 그리고 우리가 일하고 있는 코드와 연관된 코드가 무엇이 있는지 알기 어렵다면, 우리는 나쁜 프로젝트 구조와 아키텍처를 가지고 있는 것이다.

Slide 55

Slide 55 text

Copyright ⓒ All Right Reserved by Buzzvil [2011] Screaming Architecture Your architectures should tell readers about the system, not about the frameworks you used in your system. If you are building a health-care system, then when new programmers look at the source repository, their first impression should be: “Oh, this is a heath-care system”. Robert C. Martin 2011, Screaming Architecture

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Copyright ⓒ All Right Reserved by Buzzvil 여기까지 단일 서비스 … 이제부터 분산 서비스(시스템) Event-Driven Architecture From CQS to CQRS - Command Pattern - Command Bus Service Oriented Architecture - CORBA - Web Services - Message Queue - Enterprise Service Bus - Microservices 는 다음 편에 And so on...