이것저것IT

모놀리식 아키텍처 vs 마이크로 서비스 아키텍처 모놀리식 아키텍처 애플리케이션이 배포 가능한 하나의 산출물로 생성이 된다. 모놀리식 아키텍처의 장점은 구축 및 배포가 쉽다. 하지만 애플리케이션의 크기와 복잡성이 증가하면 모놀리식으로 관리를 하는것은 어렵다. 하나의 변경으로 다른 부분까지 영향을 준다면 사용자가 서비스를 다시 접하는 시간이 길어질것이다. 단점으로 몇가지가 더있다. 느린 개발 속도 – 대규모 모놀리식 애플리케이션에서는 개발이 더욱 복잡해지고 속도가 느려집니다. 확장성 – 개별 컴포넌트를 확장할 수 없습니다. 안정성 – 모듈에 오류가 있으면 애플리케이션 전체의 가용성에 영향을 줄 수 있습니다. 기술 채택의 장벽 – 프레임워크 또는 언어를 변경하면 애플리케이션 전체에 영향을 미치므로 변경 시 비..

만약 내가 상품서비스를 만든다고 했을때 1,2,3 과 같은 로직이 필요할것이다. 정보를 조회하기 위해서 JPA에 의존을 하고 결제를 하기 위해서 PG 결제에 의존을 하고 주문완료후 이메일 발송을 위해서 이메일 발송 서비스에 의존을 할것이다. 과연 이와 같은 구조가 옳바른 구조일까?? 만약 JPA가 아닌 QueryDSL로 조회 로직을 바꾼다면 orderService까지 코드를 수정해야하는 경우가 생긴다. 그럼 어떤 식으로 설계를 해야 orderService는 안바꾸고 low레벨만 수정을 해도 로직에는 문제가 없을까?? 그 답은 "인터페이스"에 있다. 위 그림과 같이 orderService가 조회로직 인터페이스를 바라보는 거는 상관이 없다 왜냐하면 같은 도메인 레이어 이기때문이다. 인터페이스를 두면서 의존성..

계층형 아키텍처의 문제는 무엇일까? 웹 -> 도메인 -> 영속성 전통적인 웹 애플리케이션은 이와 같이 구성이 되있다. 이럼 이런 구조는 어떤 문제가 있을까?? 계층형 아키텍처는 코드에 나쁜 습관들이 스며들기 쉽게 만들고 시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들을 노출한다. 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다. 웹 계층은 도메인 계층에 의존을 하고 도메인 계층은 영속석 계층에 의존하기 때문에 자연스럽게 데이터베이스에 의존하게된다. 테스트하기 어려워진다. 모킹 해야할 대상이 많아지면서 테스트하는게 힘들어진다. 유스케이스를 숨긴다. 개발자들은 새로운 유스케이스를 구현할때 새로운 코드를 짜는것을 선호한다. 이런 과정이 반복이 되면 여러 개의 유스케이스를 담당하는..