나의 개발 일상 기록

MSA 전환 고도화 CQRS 뷰 모델 구현 CQRS 는 데이터 저장소에 대한 읽기 및 업데이트 작업을 구분 하는 명령과 쿼리의 역할 분리를 의미합니다. 응용 프로그램에서 CQRS 를 구현 하면 성능, 확장성 및 보안을 최대화할 수 있습니다. CQRS 로 마이그레이션하여 시스템은 시간이 지남에 따라 개선 되고 업데이트 명령으로 인해 도메인 수준에서 병합 충돌이 발생 하는 것을 방지 할 수 있습니다. 1. monolithic 에서 MSA 로 전환이 진행될수록 여러 서비스의 API 를 호출해야만 하는 케이스가 생겨나게 됩니다. 가령 주문 상세 페이지의 경우 유저 / 상품 / 주문 / 쿠폰 등의 조회 API 를 호출해야 페이지 구성이 가능한 전체 데이터를 획득할 수 있게 됩니다. 이 때 각각의 API 를 조합하..

MSA 전환_과정 단기적인 성과를 빠르게 창출하기 1. MSA 전환이라는 의사 결정을 이끌어냈다면 이제는 MSA 구조 안에서 작지만 빠른 성공을 만들어내야 합니다. MSA 전환의 장점을 팀과 구성원들에게 증명하는 시간이 필요합니다. MSA 가치를 빠르게 증멸할수록 향후 MSA 전환에 필요한 여러가지 지원을 충분히 받을 가능성 커집니다. 2. 요구사항이 복잡하지 않으면서도 유저에게 필요한 신규 기능을 찾고, 그 기능부터 신규 서비스로 빠르게 구현 기존 로직에 대한 전환은 유저와 시스템 기준에서는 변하는 것이 없기 때문에, 기존에 없는 신규 기능을 먼저 개발하는 것이 좋습니다. 복잡하지 않은 요구사항으로 새롭게 만드는 서비스이기 때문에 빠른 개발과 런칭이 가능합니다. 3. 새롭게 구현된 신규 프로젝트는 추후..

Flow설계 및 검토 선물하기 도메인의 경우 일반 주문과 달리, 주문 과정에서 배송지 주소를 확정할 수 없습니다. 선물하기 주문을 결제한 사람이 해당 주문을 지인에게 선물로 전달하고, 이 후 수령자가 본인의 배송지 주소를 입력해야 배송이 시작되는 구조이기 때문입니다. 또한, 수령자는 선물을 수락하거나 거절할 수 있는 선택이 있기에 거기에 맞는 Flow도 함께 고려를 해야합니다. 선물하기의 특성 상 배송지 주소를 주문 과정에서 확정을 지을수 없기 때문에 주문 API에 요청을 할 경우 일반적으로 3가지 방법을 사용한다고 합니다. 경우에 따라서 적절한 방법을 채택해야 합니다. 기존 주문 API 수정 기존의 API를 수정할 경우 배송지 주소는 필수값으로 처리가 되는 경우가 있는데 선물하기는 배송지 주소가 필수값..

ORDER DOMAIN Order Domain의 경우 Validation을 확인해야 할 부분들이 많았습니다. 결제 금액, 결제 수단, 결제 상태 등 돈과 관련이 되는 도메인이다보니 꼼꼼하게 많은 사항들을 살펴보아야 했습니다. Order Domain은 Order와 OrderItem, OrderItemOptionGroup, OrderItemOption간의 연관관계를 가지고 있음을 생각해볼 수 있습니다. 이 중 Order를 Aggregate Root하여 하위 객체들을 1 : N 관계로 매핑해주어야합니다. Item 메인처럼 객체 생성과정에서 Order뿐만 아니라 하위 객체들의 정합성이 일관되게 지켜질 수 있도록 하여야 합니다. 또한, OneToMany, ManyToOne 양방향 참조로 설정하고 성능과 관계설정의..

ITEM DOMAIN Item Doamin의 경우 간략하게 Item, ItemOption, ItemOptionGroup 3개의 Entity가 연관관계를 가지고 있음을 생각해볼수 있습니다. 이 중 Item은 도메인 전체의 Aggregate Root 역할을 하게 됩니다. Item Aggregate 내부에서는 데이터가 변경될 때마다 유지돼야 하는 일관된 규을 지켜야하며 일관된 규칙은 Aggregate Root에 적용되는 모든 트랜잭션 내에서 지켜져야 합니다. 만일 규칙이 깨진다면 트랜잭션 롤백을 발생한다는 것을 의미합니다. Item Aggregate 를 만들어내는 과정에서 Factory의 사용을 검토해야 합니다. Item 도메인의 경우 객체 생성 과정에서 Item뿐만 아니라 ItemOption과 ItemOpt..

응용 계층, 외부 인터페이스 계층 구현(Application, Interfaces package) Facade 구현(Application) Facade 패턴의 정의는 다양한 외부 인터페이스를 하나의 인터페이스로 통합하는 개념이라고 말할 수 있습니다. 다시 말해 복잡한 시스템 뒤단은 숨기고 간단한 인터페이스를 제공하는 객체라고 할수 있습니다. 여기에서는 비즈니스 결정을 내지진 않지만 수행할 작업을 정의하여 Transaction으로 묶여야 하는 도메인 로직과 그 외 로직을 Aggregation하는 역할로 한정 짓습니다. 로직의 조합이라는 측면을 관점으로 Facade를 차용합니다. 1. 응용 계층에서 구현해야할 Partner 도메인의 요구사항을 구현합니다. 비즈니스 규칙은 포함하지 않으며, 작업을 조정하고, ..

PARTNER DOMAIN_Entity, Service Domain Layer 구현 시 추상화 레벨을 높이는 것이 좋습니다. Domain Layer의 추상화 레벨을 높이는 이유는 추상화 레벨을 높게 가져가게 되면 Domain Layer의 요구사항의 가독성이 높아지며 세세한 구현과 Low Level에 해당하는 기술은 Infrastructure Layer에 위임을 하기 때문에 코드의 변경이나 기술의 변경에 자유로워 집니다. 또한, Domain Layer의 핵심은 Entity와 특정 서비스를 읽으면 전체 도메인의 흐름을 파악할 수 있어야 하기 때문에 Domain Layer로직과 서비스의 역할에 대해서 분리가 이루어져야 합니다. Entity 구현 1. 객체 관점에서 필수 속성과 메서드를 정의하여야 합니다. Se..

좋은 구현이란? 강의를 통해 좋은 코드를 구현하는 방식에 대해서 알게 되었습니다. 많은 개발자들간에 코드로 소통이 이루어지기 위해서는 잘 짜여진 코드의 요건들이 존재하는 것을 알게 되었습니다. 어떠한 요건들이 있는지 정리를 해보았습니다. 1. 비즈니스 가치를 명확히 충족시켜야 합니다. 처음 개발에 입문하였을 때 많은 기술을 익히고 자유롭게 사용하면서 다양한 퍼포먼스를 보여주는 것이 개발자라고 생각하였습니다. 그렇지만 회사의 비즈니스 가치와 상관없이 기술적 성취에만 관심을 가진다면 회사와 개발자 서로 간의 목표를 달성하는 부분에 있어 어긋나는 경우가 발생하게 된다면 성공적인 성과를 낼 수 있을까라는 생각이 들었습니다. 기술은 도구일 뿐이고 그 도구를 활용하여 익숙해지고 좀 더 좋은 도구를 찾는 근원적인 이..

Hystrix Monitoring With Turbine Hystrix를 간략히 설명하자면 관련 서비스에 대한 호출 실패에 대한 method를 감시하고 있습니다. 실패가 있는 경우 Circuit Open하여 Fallback을 호출하여 전달해줍니다. 각 method에 @HystrixCommand를 달아 놓고 잘 동작하는지를 Monitoring 할 수 있는 Dashboard를 Hystrix에서 제공을 해줍니다. Hystrix Dashboard는 single instance에 대해 @HystrixCommand가 정의된 method에 대한 Monitoring을 수행할수도 있게 해주고 Turbine을 이용해 multi instance에 대해 @HystrixCommand가 정의된 method에 대한 모니터링을 수행..

MSA 운영 환경을 위한 전용 모니터링 도구들 간략 정보 - Zipkin, Turbine - 1. 분산 Tracing에서 서버간 Trace 정보의 전달 서버간의 Trace 정보의 전달은 사용 Protocol의 헤더를 통해 전달이 필요합니다. ex) HTTP Header In Process에서 Trace 정보의 전달 문제 다양한 Library에 의한 Thread 변경으로 인한 Trace 정보의 전달이 어려움이 있습니다. - 단순한 Thread Local에 저장하는 방식을 사용하기 어렵습니다. - Hystrix, RxJava, @Asynx, 등 ... 1. Zipkin 마이크로서비스아키텍쳐(MSA) 환경에서는 하나의 서비스 호출을 통해 내부적으로 여러개의 서비스가 호출될 수 있습니다. 그렇기 때문에 특정 구..