아키텍쳐 설계 경험4 [신입 개발자의 첫 번째 아키텍쳐 설계 도전기 - Fin] 신규 아키텍쳐의 기대효과와 개선점 지금까지 레거시 아키텍쳐의 문제점을 분석하고, 이를 개선하기 위한 헥사고날 아키텍쳐의 도입과 설계에 대해 다루었습니다.이번 마지막 글에서는 실제로 새 아키텍쳐가 어떤 효과를 가져왔는지를 구체적인 예시와 함께 살펴보겠습니다.1. 풍부한 도메인 모델을 통한 비즈니스 로직의 응집도 향상레거시 코드// TransactionCoreService 클래스(서비스 레이어)에서 일일이 총액을 계산fun tranSaleHeaderGenerate( transactionInformation: PaymentEndRequestDTO, paymentData: PaymentsReqResData): TranSaleHeader { val cardAmt = BigDecimal(credit.sumOf { it.request.. 2025. 1. 5. [신입 개발자의 첫 번째 아키텍쳐 설계 도전기 - #2] 헥사고날 아키텍처 도입과 설계 오늘은 레거시 아키텍쳐의 문제점을 개선하기 위해 헥사고날 아키텍쳐의 설계와 실제 구현에 대해 다루어 보겠습니다.1. 왜 헥사고날 아키텍처인가?이전 글에서 분석했던 레거시 아키텍처의 핵심적인 문제점들은 아래와 같았습니다.core 모듈의 순수성 훼손의존성 방향의 혼란서비스 레이어의 정체성 혼란비즈니스 로직의 산재빈약한 도메인 모델이러한 문제들을 해결하기 위해서는 명확한 경계와 의존성 규칙이 필요했습니다.헥사고날 아키텍처는 이러한 요구사항을 만족시키는 제가 알고 있는한 최적의 선택지였습니다.2. 새로운 아키텍처의 구조2.1 모듈 구조새로운 아키텍처는 크게 다음과 같은 구조를 가집니다:shared: 공유 로직을 포함하는 최상위 모듈application: 핵심 비즈니스 로직 담당adapter: 외부 세계와의 통신.. 2025. 1. 5. [신입 개발자의 첫 번째 아키텍쳐 설계 도전기 - #1] 레거시 아키텍처의 문제점 분석 1. 레거시 아키텍처의 구조와 문제점기존 POS 시스템은 common-core-windows의 3계층 구조로 설계되어 있었습니다.common은 영속성 계층을, core는 비즈니스 로직을, windows는 컨트롤러 역할을 담당했습니다.얼핏 보면 깔끔해 보이는 이 구조에는 몇 가지 문제점들이 있었습니다.1.1 표현력이 너무 부족하다먼저, 오프라인 결제 솔루션은 그 특성상 외부 세계에 대한 의존성을 굉장히 많이 가지는데요.몇 가지 예를 들어 보아도 아래처럼 여러 외부 의존성을 가진다는걸 금새 알 수 있습니다.1. 다양한 VAN사 결제 모듈 연동2. 다양한 상품권사 API 연동3. 배달, 선주문 앱 등의 다양한 주문 채널 연동4. 다양한 기종의 프린터 연동이 외에도 고객사의 멤버십 관리를 해주는 업체와의 연동 .. 2024. 12. 16. [신입 개발자의 첫 번째 아키텍쳐 설계 도전기 - 프롤로그] 입사 1년차 선물로.. 중요한 자사 프로젝트의 설계를 맡게 되었다!? 예상치 못한 선물2024년 9월, 입사 1년을 갓 넘긴 시점에서 저는 뜻밖의 '선물'을 받았습니다.병역 특례로 복무하던 제 사수분이 퇴사하게 되면서, 사내의 가장 중요한 프로젝트 중 하나인 크로스플랫폼 POS의 아키텍쳐를 설계하고 개발을 리딩해야 하는 상황이 되었기 때문입니다.두려움과 설렘 사이사실, 프로젝트를 리딩해 나가야 되는 상황인 건 맞았지만, 아키텍쳐를 새로 설계해야 된다는 책임이 부여된건 아니었습니다.하지만, 저는 짧다면 짧은 1년간 레거시 코드를 유지보수하고 추가 개발을 하면서, 기존의 아키텍쳐와 개발 방법에 많은 문제가 있다는 것을 느끼고 있었습니다.하여, 어차피 할 거라면 신규 프로젝트니까 아키텍쳐 부터 탄탄하고 깔끔하게 만들고 가자는 생각이 들었습니다.위와 같은 상황이었기에 처음에는 정.. 2024. 12. 16. 이전 1 다음 728x90
