개발자취

신규 MSA프로젝트를 진행하면서 고민됐다. 이벤트 발행은 어떻게 해야하고 어떻게 받아야할까? 필요한 이벤트를 달라고 요청을 하고 이벤트로 받아야 하나? 이벤트가 날라오면 필요한 정보를 요청해야하나? 이렇게 생각했는데 생각해보니 이러면 기존 프로젝트는 메세지를 발행하는데 메세지에 특정목적이 생겨버린꼴... 그리고 저렇게 3, 4 번의 과정의 경우 저게 분리가 맞을까? 기존 서비스가 죽으면 신규 프로젝트도 같이 죽는데?? 분리가 맞아? 틀린 방법이였다. 에초에 메시지큐에는 회원가입함, 상품을 수정함, 배송을 시작함 등과같은 발행하는 프로젝트 입장에서 메세지를 발행하고 구독하는 서비스는 알아서 필요한 데이터를 가져다 쓰는것이다. 서로 간섭이 없고 두 서비스중 하나가 죽는다고해서 같이 죽는게 아닌 상황이 되버린..

신규 프로젝트를 들어가며 MSA설계를 하게됐는데.. 어디까지, 어느정도 분리해야하는지 자연스럽게 고민하게 됐다. 신규 프로젝트에 각각의 서비스를 서브도메인으로 분리한후 서브도메인으로 분리해야하나? 처음엔 각 서비스별로 DB를 두고 별도로 운영하는게 좋지않을까? 생각했다. 근데 이게 과연 맞을까? 서비스의 용도를 고려하지않은 설계였다. 프로젝트 A의 경우 트레픽이 많지 않을것으로 예상되었기에 이렇게 진행하는것은 아니라고 판단. 프로젝트 A의 경우 DB를 굳이 나눌 필요가 없다고 판단되었다. 다만 트래픽이 많을것으로 예상되는 서비스3의 경우는 따로 분리해서 서비스하는게 맞다고 결론이 났다. 단순히 MSA를 위한 무조껀적인 분리가 아닌 상황에 따라 범위를 정하고 기술적으로 나누지말고 서비스의 성격, 서비스의 ..

이벤트를 이용해 도메인이 뒤섞이는 문제는 해결을 했지만 외부시스템의 성능에 영향을 받는건 해결이 안됬음. 가장 쉽게 생각할수있는 해결방안은 비동기로 처리하는것 카톡알림이나 이메일 알림같은경우 10초 20초 정도 늦게 도착해도 전혀 문제될게 없어보인다. A를 하면 일정시간안에 B를 해라 같은 경우에 비동기 처리를 하면 해결될것같다. 비동기 이벤트 로컬 핸들러를 비동기로 실행 메시지 큐 사용 이벤트 저장소와 이벤트 포워더 사용 이벤트 저장소와 이벤트 제공 API 사용 1. 로컬 핸들러를 비동기로 실행 @Service public class OrderCanceledEventHandler{ // ... @Async @EventListener(OrderCanceledEvent.class) public void h..

시스템간 강결합에 의해 문제가 생기는 경우를 먼저보면 예를들어 쇼핑몰에서 사용자가 구매취소하면 환불처리해야하는데, 그림처럼 환불기능 실행 주체는 주문 도메인으로 잡았고 도메인 서비스를 주입하지않고 파라미터로 받아와서 주문상태를 변경하고 결재 상태를 변경하도록 코드를 짰다. 근데 이 코드엔 문제가 있다. 주문 도메인 객체에 환불 로직이 뒤섞여버리는 설계상의 문제가 있다. 또, 보통 결재의 경우 외부 API를 이용하는데 외부에 문제가 있어서 오작동한다면 트랜잭션은 어떻게 처리해야할지?, 외부 시스템의 성능이 느리다면 직접적인 영향을 받을수있는데 이건 어떻게 해야할지? 생각해봐야합니다. 트랜잭션의 경우 문제가 생기면 롤백하는 방법이 있겠지만 일딴 주문 취소한건 취소한거고 환불은 나중에 다시 처리하는 방법이 있..

레이어 분리 각 관심가 별로 4개의 레이어로 분리 표현계층 응용계층 도메인계층 인프라스트럭처 표현계층 사용자가 시스템을 사용할 수 있는 화면이나 흐름을 제어한다. 사용자의 요청을 알맞은 응용서비스에 전달하고 결과를 사용자에게 제공한다. 최범균 님의 도메인주고개발 시작하기 에서 말하길 꼭 응용서비스를 거쳐야 할 필요는 없고 단순 조회만의 기능 같은 건 표현계층에서 바로 DAO나 리포지토리에 붙는 것도 좋다고 함. 세션을 관리한다. 여기서 사용자는 사람뿐 아니라 외부 시스템일 수 있다. 응용계층 사용자가 요청한 기능을 실행한다. 업무로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다. 주로 도메인 객체 간의 흐름을 제어하는 형태를 갖는다. 도메인 로직을 응용서비스에 넣게 되면 응집성이 떨어지..

트랜젝션 스크립트 패턴 서비스 계층에서 직접 DB에 붙어서 비즈니스 로직을 처리하는 것. 비즈니스 로직이 복잡할수록 트랜젝션 간에 비즈니스 로직이 중복되기 쉽다. 중복된 코드가 동기와 되지 않으면 일관성 없는 동작이 발생하기 쉽다. 그로 인해 유지보구사 어려운 거대한 진흙 덩이가 될 가능성이 큼 액티브 레코드 패턴 객체 모델(Entity)을 만들어서 사용. 끽해봐야 getter, setter 정도이며 save() 정도 정의. 도메인 모델 액티브 레코드와 다르게 비즈니스 로직을 모델에 위임. /*액티브 래코드*/ public void service(){ User user = new User(); user.setEmail("배고파@naver.com") } public class User{ private St..

용어 네이버 사전을 검색해봤을때 bounded : 경계가 있는, 칸막이 된 context : 맥락, 전후사전 이렇게 검색이 된다. 말 그대로 해석하면 경계가 있는 맥락 정도로 해석하면 될꺼같음. 알아보기에 앞서 일딴 우리가 개발을 계속 해 나가다 보면 한가지 주제에대해서 기능이 계속 붙어나가고, 다른기능과 강한 결합을 맺게되기도하는데 그렇게 계속 붙여나가다보면 너무 거대해진다. flowchart LR A B C D E F G H I(...) G(...) K(...) A --> B --> C --> A --> D -->E --> F --> G --> E --> H --> I H -- > A --> B --> C --> E --> H C --> A --> H --> G --> B B --> K --> H 크..

모노리식 아키텍처 기존 전통적인 아키텍처. 하나의 서비스 또는 애플리케이션이 하나의 거대한 아키텍쳐 하나로 똘똘 뭉쳐있다보니 내부 의존성이 강함 스케일 아웃의 대상은 모노리스 전체가 됨. 장점 작은 규모의 프로젝트작업이 용이함 개발환병이 복잡하지않음 End to End 테스트가 용이함.단점 프로젝트 규모가 커질수록 빌드, 배포 시간이 길어짐. 작은 수정에도 전체를 빌드하고 배포해야함 유지보수가 힘들어짐 일부의 기능(오류)이 전체에 영향을 줌 기능별로 원하는 기술을 선택하는데 까다로움 이런 모놀리식에서 벗어나고자 강한 내부 의존성을 벗어나고자 분리를 함. 너무 분리 하니 글로벌 복잡성이 높아지게됨. 로컬 복잡성과 글로벌 복잡성의 중간지점이 DDD라고 보면 됨. DDD의 핵심 요소 느슨한 결합도 놉은 응집도..