본문 바로가기

전체 글170

[Micro Service] Micro Service 상세 설계(도메인 모델링, 헥사고날 구조, 엔티티, Value object, 표준타입, 애그리거트, 도메인 서비스 및 이벤트) 2장 ◆ 도메인 모델링 ▶ 마이크로서비스의 내부 구조는 폴리글랏하게 접근할 수 있는데 폴리글랏하다 라는 의미는 애플리케이션을 구현하는 언어나 데이터를 저장하는 저장소를 서비스마다 다양하게 활용할 수 있다는 의미인 동시에 내부 아키텍처 구조를 서비스 특성에 맞게 다양하게 수립할 수 있다는 의미이기도 하므로 서비스의 내부 영역의 구조를 도메인 모델 중심으로 만들 수도 있고 트랜잭션 스크립트 형태로 만들 수도 있음 ▶ 도메인 모델 형태의 헥사고날 구조 ▶ 단순한 로직인 경우에는 트랜잭션 스크립트 구조로 만들어도 무방하지만 비즈니스가 복잡해질수록 비즈니스 개념들을 잘 구조화할 수 있는 도메인 모델 구조가 효과적 ▶ 도메인 모델 구조는 복잡함을 다루어 쉽게 표현할 수 있는 구조를 제공하기 때문인데 이러한 내부 구조를 .. 2023. 5. 4.
[Micro Service] Micro Service 상세 설계(프런트엔드 모델링, 백엔드 모델링, API 설계) 1장 ◆ 마이크로서비스 상세설계 ▶ 프런트엔드 모델링 ● 웹과 모바일 기술의 발전에 따라 사용자 경험에 민감하게 반응할 수 있는 ui 기술과 개념이 등장했고 이를 잘 지원할 수 있는 다양한 프런트엔드 프레임워크가 등장 ● 대표적인 프레임워크로 앵귤러(Angular), 리액트(React -> next), 뷰(Vue.js) 등이 있고 모두 사용자 경험을 잘 지원하는 SPA(Single-Page Application)를 지원 ● 이러한 경향은 프런트엔드에서 수행해야 할 일들이 점점 많아지고 중요해졌음을 의미 ● 프런트엔드 영역의 모노리스 구조를 분리하기 위한 마이크로 프런트엔드 등의 패턴이 등장하고 있으며 갖가지 유연한 아키텍처 등이 소개되고 있음 ● 최소한의 설계 영역 ⊙ 프런트 아키텍쳐 정의 ⊙ 표준 레이아웃 .. 2023. 5. 2.
[Micro Service] Micro Service 설계(이벤트 스토밍 워크숍 진행, 엑터 도출, 애그리거트 정의, 바운디드 컨텍스트, 컨텍스트 매핑) 2장 ◆ 이벤트 스토밍을 통한 마이크로서비스 도출 ▶ 이벤트 스토밍 워크숍 진행 ● 워크숍 진행 ⊙ 액터 도출 → 커맨드까지 찾고 나면 커맨드를 실행하는 액터(Actor)를 도출하는데 액터는 사용자 또는 조직, 역할자를 의미 → 액터는 추상적으로 식별하지 않고 비즈니스를 수행하는 구체적인 역할을 고려해서 도출 → 단순히 모든 업무에서 보편적으로 사용되는 회원이나 관리자로 정의하지 않고 특정 비즈니스를 실제로 수행하는 판매자, 구매자, 상품 관리자, 배송 관리자, 시스템 관리자와 같이 명확한 역할자를 도출하려고 노력해야 함 → 액터를 도출하면서 이전에 식별하지 못했던 커맨드와 도메인 이벤트가 추가로 도출될 수 있는데 이 경우에도 추가로 식별되는 사항들을 모델링 공간에 붙이면 됨 → 액터는 노란색의 작은 포스트잇.. 2023. 5. 2.
[Micro Service] Micro Service 설계(이벤트 스토밍 워크숍 진행, 도메인 이벤트 찾기, 외부 시스템 도출, 커맨드 도출, 핫스폿 도출) 1장 ◆ 이벤트 스토밍을 통한 마이크로서비스 도출 ▶ 마이크로서비스 간의 의존성을 줄이기 위해서는 아키텍처 영역에서 언급했다시피 서비스 간 비동기 메시지 기반 도메인 이벤트를 활용하는 것이 중요한데 이러한 도메인 이벤트를 통한 의존 관계를 식별하는 방법이 쉽지 않은데 이를 위해 알베르토 브란돌리니(Alberto Brandolini)라는 이탈리아 출신의 DDD 컨설턴트가 DDD 설계를 가속화할 수 있는 이벤트 스토밍(event storming)이라는 설계 기법을 고안해 냈는데 이벤트 스토밍은 이벤트 중심으로 이해 관계자들이 모여 브레인 스토밍하는 워크숍을 의미 ▶ 이벤트 스토밍은 모든 이해 관계자가 모여 서로가 가지고 있는 각 관점을 논의하며 그 차이점을 이해하고 공유할 수 있다는 점에서 기존 방법론에서 장기간.. 2023. 4. 28.
[Micro Service] Micro Service 설계(컨텍스트 맵핑, 공유 커널, 소비자와 공급장, 준수자, 충돌 방지 계층, 공개 호스트 서비스, 컨텍스트 맵) 2장 ◆ DDD에서의 설계 ▶ 유비쿼터스 언어와 도메인 모델, 바운디드 컨텍스트 ● 유비쿼터스 언어는 특정 도메인의 업무 개념을 표현하는 언어 ● 결제 도메인에서의 고객과 배송 도메인에서 고객은 의미가 다른데 결제 도메인에서는 구매하기 위해 상품을 결제하는 역할에서의 고객 즉 결제를 위한 신용카드 정보나 계좌 정보를 가진 결제자를 의미하고 배송 도메인에서는 구매한 상품을 배송받는 역할 즉 상품을 받을 주소와 우편번호, 전화번호를 소유한 수취자를 의미하기 때문에 이러한 개념을 고객으로 포괄적으로 표현해서는 안됨 ● 명확하게 결제 서비스에서는 결제자의 개념으로 배송 서비스에서는 수취자의 개념으로 모델링해야 하는데 그래야 결제 서비스나 배송 서비스를 담당하는 팀의 의사소통이 명확해짐 ● 도메인에 특화된 개념이 유비.. 2023. 4. 27.
[Micro Service] Micro Service 설계 1장 ◆ Micro Service 설계 ▶ 소프트웨어 개발의 역사에서 모듈화의 중요성은 예전이나 지금이나 한결같은데 모듈화의 근본적 가치는 각 모듈을 기능적으로 응집성 높게 만들고(high cohesion) 기능이 다른 타 모듈 간의 의존도를 낮추는 것(low coupling) ▶ 마이크로서비스 설계에서의 가장 중요한 관심사도 어떻게 기능적으로 응집성있는 마이크로서비스를 도출하고 타 서비스 간의 의존도는 낮출 것인가 하는 것이고 마이크로서비스의 내부 구조를 구성하는 각 요소들도 역할별로 모듈화 돼야 하는데 역할 별로 모듈화 된다는 말은 각 역할이 분명한 응집성 있고 서로 의존성이 낮은 모듈들이 모여 마이크로서비스를 이루고 이 마이크로서비스는 다른 마이크로서비스와 의존성이 낮아야 한다는 의미 ▶ 다른 방식으로 .. 2023. 4. 26.
[MicroService] Micro Service Application Architecture(아키텍처 정의, Micro Service 도출, MDD, DDD, 빌드 및 배포) 3장 ◆ 기민한 설계 / 개발 프로세스 ▶ 아키텍처 정의와 Micro Service 도출 ● 아키텍처 정의 ⊙ Micro Service 외부/내부 아키텍처를 정의하는 공정 ⊙ 로버트 c. 마틴은 기술 세부사항은 늦게 결정할 수 있어야 한다고 언급한 바 있는데 이것은 기존의 워터폴한 개발 프로세스에서 강조했던 아키텍처 등의 기술 결정사항이 모두 완벽하게 정의된 후 개발을 해야 한다는 말과 배치됨 ⊙ Micro Service를 순수 비즈니스 로직이 존재하는 내부 영역과 기술 영역을 표현하는 외부 영역으로 구분해서 개발하면 외부 영역은 언제든지 교체될 수 있으므로 애플리케이션의 핵심인 내부 영역에 집중하고 외부 영역 즉 아키텍처의 결정사항들은 천천히 결정해도 된다는 의미로 그만큼 애플리케이션은 소프트 즉 유연해야 .. 2023. 4. 26.
[Instrument] Required reports under IFR(AIM 5-3-3) Additional Reports(AIM 5-3-3) ★ 항상 보고해야 할 것들 1. "고도" 배정 받은 고도를 떠나거나 새로운 고도를 받았을 때, VFR-on-TOP으로 고도를 변경할때, 즉 항로에서 고도가 바뀔때는 보고해 줘야 한다. 2. "상승/강하율" 500fpm 이상의 변화를 주지 못할 때 보고를 해야한다. 3. "Approach has been missed" 는 기존 계획했던 공항으로의 접근이 중단되었을 때 Missed를 의미하며 Alternate airport로 Clerance를 재용청하거나 다른 계기접근을 요청하는 등의 경우를 의미한다. 4. Flight plan에 제출한 "속도"와 실제 비행할때의 평균 TAS속도가 5%, 10knots 중 큰 것 이상 나타날 경우에는 보고해야 한다.(20.. 2023. 4. 25.
[MicroService] Micro Service Application Architecture(저장소 처리 어댑터, 도메인 이벤트 발행 어댑터, 도메인 이벤트 핸들러, Agile Process ) 2장 ◆ Micro Service의 내부 구조 정의 ▶ 외부 영역 – 세부 사항 ● 외부 영역은 내부 영역의 서비스 인터페이스를 사용하는 인바운드 어댑터와 내부 영역에서 선언한 아웃바운드 인터페이스를 구현하는 다양한 어댑터로 구성 ● 어댑터는 플러그인처럼 언제든지 교체되거나 확장될 수 있어야 하기 때문에 내부 영역이 먼저 정의된 후에 외부 영역의 세부사항은 늦게 정의돼도 상관없도록 해야 하는데 이 같은 방식이 소프트웨어를 부드럽게(Soft) 만듬 ● 어댑터 ● API 퍼블리싱 어댑터 ◎ API 퍼블리싱 어댑터는 REST API를 발행하는 인바운드 어댑터 ◎ 내부 영역의 서비스 인터페이스를 호출해서 REST 형식의 API로 제공 ◎ 명시적인 REST 리소스 명칭을 정의하고 각 REST 메서드가 의도에 맞게 서비.. 2023. 4. 24.
[MicroService] Micro Service Application Architecture(내부 아키텍쳐, 애그리거트 패턴, 도메인 모델 패턴, 트랜잭션 스크립트 패턴 ) 1장 ◆ Micro Service의 내부 구조 정의 ▶ 바람직한 Micro Service의 내부 아키텍처: 클린 Micro Service ● 지금까지 언급한 아키텍처 구조는 점점 복잡해지는 모노리스 소프트웨어를 통제하기 위해 오랫동안 고민해온 결과로 그에 비해 Micro Service는 복잡해진 모노리스의 각 기능들을 쪼개기 때문에 어느 정도 복잡성을 덜어낼 수 있지만 분리해도 복잡성은 이전되고 그 안의 복잡성을 통제할 필요가 있다는 사실은 변하지 않음 ● Micro Service의 내부 구조를 정의할 때 반드시 고려해야 할 한 가지는 Micro Service 시스템에서 정의해야 할 마이크로서 비스의 내부 구조가 다양할 수 있다는 것인데 왜냐하면 Micro Service는 앞에서 살펴본 것처럼 자율적인 Mic.. 2023. 4. 24.
[MicroService] Micro Service Application Architecture(아키텍쳐 문제, 레이어드 아키텍쳐, 헥사고날 아키텍쳐, 클린 아키텍쳐 ) 1장 ◆ Micro Service Application Architecture → 로버트 C. 마틴(Robert C. Martin)은 클린 아키텍처에서 소프트웨어의 가치는 행위 가치와 구조 가치로 나뉘고 소프트웨어를 정말로 부드럽게(Soft) 만드는 것은 구조 가치라고 언급한 바 있는데 여기서 행위 가치는 소프트웨어의 기능을 말하며 구조 가치는 소프트웨어 아키텍처를 의미하는데 그는 토끼와 거북이의 경주를 예로 들며 가장 빨리 가는 방법은 제대로 가는 것이며 코드와 설계의 구조를 깔끔하게 만들려는 생각을 하지 않고 기능 구현만 목적으로 삼으면 소프트웨어가 엉망이 된 상황에 대처하는데 더 많은 비용이 든다는 점을 강조 → 단기간의 프로젝트 동안 애플리케이션 구조나 설계에 신경 쓰지 않고 오직 기능 구현 에만 몰두.. 2023. 4. 22.
[MicroService] MSA의 이해(애플리케이션 패턴, CQRS 패턴, API 조합과 CQRS, 이벤트 소싱 패턴 ) 5장 앞어서 4장에 애플리케이션 패턴을 보지 못하였다면 4장을 읽고 오도록 하자 https://joylucky7.tistory.com/53 [MicroService] MSA의 이해(Micro Service 운영과 관리를 위한 플랫폼 패턴, 애플리케이션 패턴) 4장 ◆ MSA 구성 요소 및 MSA 패턴 ▶ Micro Service 운영과 관리를 위한 플랫폼 패턴 ● MSA 기술 변화 흐름 ⊙ 앞에서 언급한 패턴들은 모두 모노리스 시스템이 여러 조각의 Micro Service로 나눠져서 발생하 joylucky7.tistory.com ◆ MSA 구성 요소 및 MSA 패턴 ▶ 애플리케이션 패턴 ● 데이터 일관성에 대한 생각의 전환: 결과적 일관성 ⊙ 모든 애플리케이션에는 비즈니스 처리를 위한 규칙이 있고 이러한 비즈.. 2023. 4. 21.

티스토리툴바