마이크로서비스 스타일로 만들어진 시스템을 모노리틱 스타일로 이관한 사례와 함께 스프링을 이용해 모듈형 모노리스(modular monoliths)를 만든 경험을 바탕으로 모노리틱/마이크로서비스 보다 본질적인 문제를 제기하고, 문제 해결을 위한 아이디어와 코드를 공유합니다.
https://github.com/arawn/building-modular-monoliths-using-spring
이 자료는 2019년 KSUG 세미나에서 진행한 "잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다"를 기반으로 몇가지 내용을 추가하고, 전개 방식을 다듬어 조금 더 친절하게 만들어졌습니다.
마이크로서비스 스타일로 만들어진 시스템을 모노리틱 스타일로 이관한 사례와 함께 스프링을 이용해 모듈형 모노리스(modular monoliths)를 만든 경험을 바탕으로 모노리틱/마이크로서비스 보다 본질적인 문제를 제기하고, 문제 해결을 위한 생각을 공유합니다.
https://github.com/arawn/building-modular-monoliths-using-spring
The eBay Architecture: Striking a Balance between Site Stability, Feature Ve...Randy Shoup
eBay architects Randy Shoup and Dan Pritchett give a guided tour of the eBay architecture. They cover the evolution of the technology stack from Perl to C++ to Java. And they discuss scaling strategies for the data tier, application tier, search, and operations.
Explanation of the fundamentals of Redux with additional tips and good practices. Presented in the Munich React Native Meetup, so the sample code is using React Native. Additional code: https://github.com/nacmartin/ReduxIntro
Getting started with the reactjs, basics of reactjs, introduction of reactjs, core concepts of reactjs and comparison with the other libraries/frameworks
Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
마이크로서비스 스타일로 만들어진 시스템을 모노리틱 스타일로 이관한 사례와 함께 스프링을 이용해 모듈형 모노리스(modular monoliths)를 만든 경험을 바탕으로 모노리틱/마이크로서비스 보다 본질적인 문제를 제기하고, 문제 해결을 위한 아이디어와 코드를 공유합니다.
https://github.com/arawn/building-modular-monoliths-using-spring
이 자료는 2019년 KSUG 세미나에서 진행한 "잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다"를 기반으로 몇가지 내용을 추가하고, 전개 방식을 다듬어 조금 더 친절하게 만들어졌습니다.
마이크로서비스 스타일로 만들어진 시스템을 모노리틱 스타일로 이관한 사례와 함께 스프링을 이용해 모듈형 모노리스(modular monoliths)를 만든 경험을 바탕으로 모노리틱/마이크로서비스 보다 본질적인 문제를 제기하고, 문제 해결을 위한 생각을 공유합니다.
https://github.com/arawn/building-modular-monoliths-using-spring
The eBay Architecture: Striking a Balance between Site Stability, Feature Ve...Randy Shoup
eBay architects Randy Shoup and Dan Pritchett give a guided tour of the eBay architecture. They cover the evolution of the technology stack from Perl to C++ to Java. And they discuss scaling strategies for the data tier, application tier, search, and operations.
Explanation of the fundamentals of Redux with additional tips and good practices. Presented in the Munich React Native Meetup, so the sample code is using React Native. Additional code: https://github.com/nacmartin/ReduxIntro
Getting started with the reactjs, basics of reactjs, introduction of reactjs, core concepts of reactjs and comparison with the other libraries/frameworks
Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
파울러는 2004년의 글에서 제어의 어떤 측면이 역행되는 것인지에 대한 의문을 제기하고 의존하는 객체를 역행적으로 취득하는 것이라는 결론을 내렸다. 그는 그와 같은 정의에 기초하여 제어 역행이라는 용어에 좀 더 참신한 ‘의존성주입(DI,dependency injection)’이라는 이름을 지어줬다.
모든 어플리케이션은 비즈니스 로직을 수행하기 위해 서로 협업하는 둘 또는 그 이상의 클래스들로 이뤄진다. 전통적으로 각 객체는 협업 할 객체의 참조를 취득해야 하는 책임이 있다.
이것이 의존성이다. 이는 결합도가 높으며 테스트하기 어려운 코드를 만들어낸다.
IoC를 적용함으로써 객체들은 시스템 내의 각 객체를 조정하는 어떤 외부의 존재에 의해 생성시점에서 의존성을 부여 받는데, 의존성이 객체로 주입(inject)된다는 말이다. 따라서 IoC는 한 객체가 협업해야 하는 다른 객체의 참조를 취득하는 방법에 대한 제어의 역행이라는 의미를 갖는다.
일반적으로 IoC는 의존성주입(DI), 의존성룩업(DL) 두 개의 하위부류로 나눌 수 있으며, 일반적으로 DI를 이야기 할 때는 IoC를 가리키지만 IoC를 이야기할 때는 DI를 가리키는 것은아니다. DI도 여러 종류 (세터주입,생성자주입,메소드주입)가 있지만 DL의 경우도 의존성 풀과 컨텍스트화된 의존성룩업(CDL) 두 종류가 있다.
6. 단 하나만 존재 Aggregate 내에 포함된 특정 Entity를 가리킨다 루트(Root)
7. 경계 안의 객체는 서로 참조할 수 있지만, 경계 바깥의 객체는 루트만 참조할 수 있다 루트 이외의 Entity는 지역 식별성(Local Identity)을 지니며, 이는 Aggregate 내에서만 구분되면 된다
8.
9.
10. 각 루트 Entity는 전역 식별성을 지닌다. 경계 안의 Entity는 지역식별성을 지니며, 이러한 지역 식별성은 해당 Aggregate 안에서만 유일하다 . 루트 Entity는 궁극적으로 불변식을 검사할 책임이 있다 Aggregate의 경계 밖에서는 루트 Entity를 제외한 Aggregate 내부의 구성요소를 참조할 수 없다. 규칙
11. 데이터베이스 질의를 이용하면Aggregate의 루트만 직 접적으로 획득할 수 있다. Aggregate 안의 객체는 다른 Aggregate의 루트만 참조할 수 있다. 삭제 연산은 Aggregate 경계 안의 모든 요소를 한 번에 제거해야 한다. Aggregate 경계 안의 어떤 객체를 변경하더라도 전체 Aggregate 의 불변식은모두 지켜져야 한다
12. Entity와 Value Object를 Aggregate로 모으고 각각에 대해 경계를 정의하라 한 Entity를 골라 Aggregate의 루트로 만들고 Aggregate 경계 내부의 객체에 대해서는 루트를 거쳐 접근할 수 있게 하라 Aggregate밖의 객체는 루트만 참조할 수 있게 하라 내부 구성요소에 대한 일시적인 참조는 단일 연산에서만 사용할 목적에 한해 외부로 전달될 수 있다. 루트를 경유하지 않고는 Aggregate 의 내부를 변경할 수 없다 수행
13.
14. 객체의 생성과 재구성이라는 생명주기 전이(transition)를 캡슐화한다 어떤 객체나 전체 Aggregate를 생성하는 일이 복잡해 지거나 내부 구조를 너무 많이 드러내는 경우 Factory가 캡슐화를 제공해준다 클라이언트의 목적과 생성된 객체의 추상적인 관점을 반영하는 인터페이스를 제공한다. Factory (펙터리)
15.
16. 복잡한 객체와 Aggregate의 인스턴스를 생성하는 책임을 별도의 객체로 옮겨라 모든 복잡한 객체 조립 과정을 캡슐화하는 동시에 클라이언트가 인스턴스화되는객체의 구상클래스를 참조할 필요가 없는 인터페이스를 제공하라 전체 Aggregate를 하나의 단위로 생성해서 그것의 불변식이 이행되게 하라 수행
23. Factory를 잘 설계하기 위한 두 가지 기본 요건 1) 각 생성 방법은 원자적 (atomic)이어야 하며, 생성된 객체나 Aggregate 의 불변식을모두 지켜야 한다. 일관성 있는 상태에서만 객체를 만들어 낼 수 있어야 한다. 2) 생성된 클래스보다는 생성하고자 하는 타입으로 추상화돼야 한다. 자신에게 전달된 인자와 결합될 것이다. 추상적인 타입의 인자를 사용하라. Tip
24. 1) Value Object 는 불변적이다. 생성물이 완전히 최종적 인 형태로 만들어 진다. Entity Factory는 유효한 Aggregate 를 만들어 내는 데 필요한 필수 속성만 받아들이는 경향이 있다 2) Entity에는 식별성할당과관련된 쟁점이 있다는 것이다 Entity Factory와 Value Object Factory
25. 재구성에 사용된 Entity Factory는 새로운 ID를 할당하지 않는다. Factory의 입력 매개 변수에는 반드시 식별 속성을 포함해야 한다 객체를 재구성하는 Factory는 불변식 위반을 다른 방식으로 처리 할 것이다. 저장된 객체의 재구성
26.
27.
28. 생명주기의 중간과 마지막을 다루며, 거대한 관련 인프라스트럭처를 캡슐화하면서 영속 객체를 찾아 조회하는 수단을 제공한다. 참조하는 객체를 획득하는 방법을 제공해준다 특정 타입의 모든 객체를 (대개 모방된) 하나의 개념적 집합으로 나타낸다. 더욱 정교한 질의 기능이 있다. 컬렉션처럼 동작한다. Repository (리파지터리)
29. 데이터베이스 검색은 어디서든 이용할 수 있으며,곧바로 어떠한 객체에도 접근하게 해준다 Aggregate 내부에 존재하는 모든 객체는 루트에서부터 탐색을 토대로 접근하는 것 말고는 접근이 금지돼 있다는 점이다 문제
30. 클라이언트는 지정된 기준에 근거해 객체를 선택하는 질의 메서드를 이용해 Repository 에서 객체를 요청하는데,대개 특정 속성의 값을 선택 기준으로 삼는다 Repository 는 요청된 객체를 가져 오며, 데이터 베이스 질의 및 메타데이터 매핑에 대한 장치를 캡슐화한다 Repository 는 클라이언트에서 요구하는 기준에 근거해 객체를 선택하는 다양한 질의를 구현 및 반환할 수 있다 해결
31.
32. 잘 알려진 전역 인터페이스를 토대로 한 접근 방법을 마련하라 객체를 추가하고 제거하는 메서드를제공하고,이 메서드가 실제로 데이터 저장소에 데이터를 삽입하고 데 이 터 저장소에서 제거하는 연산을 캡슐화하게 하라 특정한 기준으로 객체를 선택하고 속성값이 특정 기준을 만족하는 완전히 인스턴스화된 객체나 객체 컬렉션을 반환하는 메서드를 제공함으로써 실제 저장소와 질의 기술을 캡슐화하라 실질적으로 직접 접근해야 하는 Aggregate 의 루트에 대해서만 Repository를 제공하고,모든 객체 저장과 접근은 Repository 에 위임해서 클라이언트가 모텔에 집중하게 하라. 수행
33. 가장 만들기 쉬운 Repository 는 질의에 구체적 인 매개변수를 직접 입력 하는 것이다 Repository 에 질의하기
34. 질의의 수가 많은 프로젝트에서는 좀더 유연하게 질의를 수행할 수 있는 Repository프레임워크를 만들 수 있다
35. 저장 · 조회 · 질의 메커니즘을 캡슐화하는 것은 Repository구현의 가장 기본적인 기능이다 타입을 추상화한다 클라이언트와의 분리를 활용한다 트랜잭션(개시, 커밋) 제어를 클라이언트에 둔다 Repository 구현
36.
37. Factory가 객체 생애의 초기 단계를 다루는 데 반해 Repository는 중간 단계와 마지막 단계를 관리하는 데 도움된다 Factory 가 새로운 객체를 만들어 내는데 반해 Repository 는 기존 객체를 찾아낸다. 찾는데 없을 경우에는 생성할 수 있지만 이는 Factory 에게 위임한다 Factory 와의 관계