System Design & Arch

God Class에 대한 용어 정리 god class는, 꼭 크기가 커야만(가지고 있는 필드가 많아야만) god class인 것은 아닙니다. 여러 layer에 걸쳐 사용되고 있다면, 또는 2개 이상의 책임을 가지고 있다면, 그 클래스를 사용(의존)하고 있는 클래스가 그 만큼 많다는 의미이고, 이는 곧 god class (또는 god class 유망주)입니다. god class는 크게 2가지 유형으로 나누어 볼 수 있습니다. (왼쪽) domain 책임은 제대로 나눴으나 여러 layer에 걸쳐 사용되는 경우 = 유형 1 (오른쪽) domain 책임을 제대로 나누지 못해 1개 이상의 책임을 가지는 경우 = 유형 2 유형 1 + 유형 2 = 유형3 이 글에서 주요하게 다루고자 하는 내용은 유형 1 God Cla..

https://martinfowler.com/bliki/PresentationDomainDataLayering.html layer를 나누는 것의 장점 1. 관심 분리 (를 통해 작업 대상 layer에 집중 가능) 마틴 파울러는 layer를 나누는 것의 최고 장점은, 작업 대상이 되는 layer에만 집중할 수 있도록 해준다는 점이라고 얘기하고 있다. It's biggest advantage (for me) is that it allows me to reduce the scope of my attention by allowing me to think about the three topics relatively independently. When I'm working on domain logic code I ..

Domain Model이란 해당 도메인에서 비즈니스적인 의미를 가지는 object 다. An object model of the domain that incorporates both behavior and data. - P of EAA Domain Model은 id 여부에 따라 두 가지로 구분할 수 있다. Entity id가 있어 각각의 개체를 고유하게 식별 할 수 있는 경우 엄밀히 불변은 아니고 시간이 지나면서 상태가 변경될 수 있는 대상임. (그러나 이와 별개로 앱단에서는 불변 객체로 처리하는 것이 좋다. 함수형.) e.g., Member VO ( value object ) id가 없음 To avoid aliasing bugs I follow a simple but important rule: val..

traditional Java EE 패턴에서의 정의 Spring에서 제공하는 @Repository 는 DAO 의미를 지닌다. (javadoc 참조) MyBatis에서 제공하는 @Mapper 는 sql mapper 의미를 지닌다. 따라서 layer는 아래와 같이 표현되어야 한다. ```kt @Service ---> @Repository ---> @Mapper ----> mapper.xml || annotation-string DAO sql mapping ``` 관습적으로 @Repository와 @Mapper를 동일한 layer로 간주하는 경우가 많은데, 서로 다른 layer로 간주해야 한다. "dao와 mapper의 차이" 로 검색해보면, 마치 두 개념이 같은 추상화 수준이며 서로 양립 불가한 것 처럼 보..

```js HTTP | | httpStatusCode는 해당 서버로부터 오는 모든 api 응답의 일관된 처리를 위한 error code로서 의미를 가짐 body: { code: ?, --> body.code는 해당 서버로부터 오는 모든 api 응답의 일관된 처리를 위한 error code로서 의미를 가짐 data: { code: ? --> body.data.code는 주로 Enum code. 특정 api 내 범위의 error, 상태 등 } } } // !!body.code 가 httpStatusCode로 모두 커버가 된다면 통합하여 1depth 줄일 수 있음!! ``` ```js @FE에서 받는 다면 http.get(`/api-1/example`) .then(resultCodeHandler( --> bo..

이번 챕터는 언제 리팩터링 해야 하는가? 어떤 코드가 리팩터링이 필요한 코드인가?에 대해서 다룬다. (적어도 나는)코드가 구조적으로 예쁘지 않아서, 보고 있자니 뭔가 마음 한켠이 불편해서, 같은 '느낌'을 감지하고 리팩터링을 하게 되는데 이런 모호한 기준을 끄집어 내서 문장으로 구체화한 챕터이다. 리팩터링이 필요한 코드가 가지고 있는 공통점, bad smell에 대해서 얘기한다. 무엇이 문제인지 알아야, 그에 따른 해결 방안도 떠올릴 수 있다. 부록B에 보면 bad smell case와 해법이 잘 정리되어 있음. 정리하면서 평소 개발하면서 정립했던 나의 개인적인 의견도 같이 적어 두었음. (인용구로 되어 있는 부분) 3.1 기이한 이름 함수든, 변수든, 클래스든 이름만 보고도 각각이 무슨 일을 하고 어떻..

martinfowler.com/bliki/CQRS.html (번역) https://martinfowler.com/bliki/CommandQuerySeparation.html CRUD를 모두 하나의 도메인 모델을 사용해 처리했었다면, CQRS는 CUD를 Command용 모델로, R을 Query용 모델로 분리하여 설계하는 방법 하지만 문서 전체에서 CQRS는 잘 들어맞는 부분에만 일부 사용할 것을 권장하고 있다. 문서에서 발췌 CQRS는 시스템의 특정한 부분(DDD 표현으로는 Bounded Context)에서만 사용돼야 하고, 시스템 전체에서 사용해서는 안 된다. 이러한 사고방식은 각 Bounded Context는 개별적으로 모델링을 해야 한다는 의미다. (Bounded Context: https://www..

그림으로 정리한 Spring MVC Application Architecture 왜 layer가 필요한가? layer를 왜 분리할까? layer를 분리한다는 것에는 어떤 의미가 있는가? layer를 나누게 되면, 다른 layer를 추상화 할 수 있다. 추상화를 잘 했다면, 관심 분리 를 통해 현재 작업하고 있는 layer에 집중할 수 있다. 다른 layer의 모듈을 부품을 갈아끼우듯 변경할 수 있다. 각 layer가 자신의 세부사항을 몰라도 상관 없도록, 잘 추상화해서 제공하고 있었다면 가능하다. 컴포넌트 간의 의존 계층 관계를 깔끔하게 유지할 수 있다. 각 layer를 넘나들면서 스파게티처럼 꼬여 있는 관계가 아니라, 위에서 아래로 떨어지는 간단한 구조 혹은 복잡한 참조는 같은 계층 내에서 끝내는 등 ..

Map과 data class는 애초에 용도와 목적이 다르다. Map은 data class 처럼 쓸 수는 있지만, 그렇게 쓰는게 Map의 올바른 사용법이라고 할 수는 없다. Data Class 대용으로 Map을 사용할 때의 단점 타입 정보가 유실되어 type safe 하지 않다는 점. 이게 가장 큰 단점이자 본질적인 단점이다. 꺼낼 때 형변환 필요해서 번거롭다. key 지정을 String으로 하다 보니 잘못된 참조에 대한 컴파일 타임 체크가 불가능하다. fragile. 어떤 필드가 어디서 사용되고 있는건지 IDE의 추적 기능 도움을 받을 수 없어 일일히 따라가보아야 한다. 리팩터링이 굉장히 어렵다.=유지보수가 어렵다. (e.g., 이 필드 삭제 해도 되는걸까?) Map을 Domain Model로 쓴다면? ..

- 제휴사 API 서버 Npay 서버 연결 작업을 각자 진행한 후, 이를 하나로 통합하는 과정에서 비즈니스 로직 코드 중복이 발생함. - 코드 중복을 해결하면서 제휴사 마다 다른 구현 사항을 고려하여 처음 설계한 아키텍쳐는, PointChangeService라는 abstract class에 공통 로직을 작성하고, 각 제휴사 마다 다른 부분은 abstract 메서드로 만들어 상속을 이용해 구현을 강제하는 방법이었음. - 그러나 서비스가 점차 커지고 코드가 복잡해지면서 순환 의존 (Cycle Dependency) 문제가 발생함. - 더불어 PointChangeService의 책임이 너무 많다는 문제점도 있었음. 결국 XXPointChangeService는 제휴사 마다 다른 구현부와 공통 비즈니스 로직을 모두..