본문 바로가기

All

 (92)
[개발생각] 도메인에서 코틀린으로 컴포지션 표현 도메인에서, 비즈니스 로직을 구현하는경우, 도메인서비스를 나누고, 해당 서비스를 조합하여, 비즈니스 로직을 구현하는 케이스가 많다.여기서 코드가 깔끔하지 않게 되는 부분이 존재한다. 아래 예제로 코드를 보면,class UserRegisterService ( val canUserJoinValidator:CanJoinTestUserValidator, val validUserChecker:ValidTestUserChecker, val rewardUserChecker:RewardTestUserChecker) { fun register(user:User) { with(user) { canUserJoinValidator.canJoinCheck(this); //can..
[개발생각] DDD에서 ApplicationListener를 어떻게 설계해야 좋은가? DDD에서는 크게 APPLICATION, DOMAIN, INFRA영역이 존재한다.결국 모든 레이어는 DOMAIN을 바라보는 관계로 구현을 하게된다. 여기서 해당 영역은 사실 명확히 경계가 존재하기에 초기 배움에서는 크게 문제가 없다.하지만, 조금만 더 프로젝트나, 개발을 진행하다보면, 찝찝한 부분이 생기는데,이게 바로, APPLICATION_LISTERNER, KAFKA_LISTENER등의 비동기 이벤트에 따른 컨슘하는 리스너를 DDD에서 어떻게 깔끔하게 구현을 하는가 이다. APPLICATION_LISTERNER, KAFKA_LISTENER는 인프라스트럭처 계층이기에 인프라스트럭처에 그 구현체가 존재하게 된다.그런데 여기서, 결국은 해당 리스너에서는 Domain의 Service, Provider등을 실..
[개발생각] 면접관 회사에서 면접을 본다.. 예전에도 면접관은 수도없이 들어갔지만.. 어느곳이든 두 부류로 나뉘는건 어쩔수없나보다. 거의 질문 1-2개정도 하면, '이 사람이다'는 아니더라도, 이 사람은 '나가리..'라는것은 바로 알수있는것 같다. 그 기준은 아래 두부류와 같다. 본인이 개발한 것을 정말 눈에 보일듯이 자세히 설명을 하는 면접자,본인이 개발한 것을 정말 내가 개발을 안한 티가 나게 설명하는 면접자. 사실 면접 합격여부는 이 기준으로 해도 큰 무리가 없다고 생각한다. 내가 정말 고민하고, 공부하고, 생각하고 개발을 했다면,절대 그 과정을 잊어버리지 않고, 상세히 말을 할수있고,장황하게 말하지 않아도 듣는사람이 바로 이해할수있는 깔끔한 설명을 할수있다. 참고로,나는 원래 기억력이 크게 좋지는 않다.그래서 다른 ..
[개발생각] Transactional(readOnly=true) 마스터-레플리카 구성의 디비에서 마스터는 Read-Write로 사용하고, 레플리카는 Read-Only로 사용하고 싶었다.(데이터베이스의 부하 분산 측면으로 레플리카를 조회성으로 적극활용하고 싶었기 때문이다.) RoutingDataSource을 확장하여, Transactional의 readOnly를 이용해서,마스터 레플리카로 DataSource를 스위칭하도록 설정을 하였다. 당연히 기대한 결과는,1) Hibernate에서 ReadOnly=true의 기본동작인 DirtyCheck를 하지않는것 (조회 성능 최적화)2) 해당 트랙잭션안에서는 레플리카 디비를 사용함에 따른 save, delete, update등의 쿼리를 사용하면, 예외를 발생하는것 위 2가지를 기대했다. 1번은 기대했던대로 동작을 하는것으로 확..
[개발아이디어] 대기열을 구현해보자. 순간적으로 트래픽이 몰리는 케이스를 방어하기위해, 대기열 기능을 만들었다. (대용량 트래픽 노이로제...직업병같다..) 우선 대기열이란, 미리 정한 특정 TPS 즉 초당 사용자의 접근을 제어하여 정해진 TPS이상으로는 시스템에서는 사용자의 활동을 제한하여, 서비스의 폭주를 막는 좋은(?) 기능이다.대용량 트래픽이 예상되는 서비스에서는 필수적인 기능이라고 해도 과언이 아니다(이렇게 해도 죽기는 하는건.. 함정 ㅋ.. 하지만 더 안정적으로 버틴다의 관점으로 봐야한다.) 대기열을 만들기 위해서는 크게 3가지 개념을 알고있어야한다. 1) 대기열큐2) 대기표3) 락 이 개념만 확실히 알고있으면, 크게 어려울것은 없지만, 동시성과 락을 사용하는것이기에, 개인에 따라서, 어려운 개념일수도있다. 우선 내가 만든 대기..
[개발생각] 조건이 많은 기능들을 앱에 노출해야하는경우 조건이 많은 기능들을 앱에 노출해야하는 경우, 상당히 API가 많아질수있다. 1) 홈화면에 카드형식의 데이터들을 노출해야할때, 각각의 카드는 노출해야하는 조건들이 다르다.- 각카드별로 노출여부 조건을 조회하는 API를 호출하고 해당 API의 응답을 클라이언트가 판단하여, 카드를 노출한다. 2) 미션탭에서, 각각의 미션의 조건이 다르다.- 각각의 미션은 미션수행의 조건이나 노출여부가 사용자마다 다르고 이또한 조건을 조회하는 API를 조회하여 노출여부를 판단한다. 일반적인 방법으로 구현을 하게되면,클라이언트에서 각각의 조건에 맞는 API들을 다수 호출하게 되고,그 API들또한 미묘하게 동일한 데이터를 포함하거나, 중복되는 호출의 API일 가능성이 높아진다. 이런 API들을 미션이나 홈카드 노출전용으로 묶어서..
[아이디어] 삼성,엘지 가전 제어, 어떻게 할까? 삼성,엘지 가전에는 AutoDr이라는 개념이 있다. 전기소비를 줄이라는 캠페인(DR)이 한국전력거래소(KPX)에서 발령이 되면, 해당 발령을 공공데이터포털의 OpenApi를 통해 이벤트를 받을수도있고, 관련한 제휴업체들은 직접 이벤트를 받을수도있다.이 이벤트를 받았을때,가전제품 특히 전기를 많이 먹는 에어콘, 온풍기등을 Off하거나, 온도를 조절하는등으로 전기사용량을 제어를 하면,전기소비를 줄일수있다. 요즘은 삼성,엘지 가전에서는 삼성스마트띵스, 엘지띵큐등으로 가전을 제어할수있는 API를 사용자에게 오픈하고 있다. DR이벤트를 받을수있고, API를 사용하여, 가전의 제어를 할수있다면, AUTODR (자동으로 전력소비를 줄이는 행위)를 할수있다. 여기서 중요한건, 해당 API를 서버에서 날리는 방법보다는..
[개발생각] 주소기반 데이터 조회를 위한 방법은? 진행중인 프로젝트에서 주소기반으로 동일한 지역, 비슷한 지역내의 사용자들의 에너지 데이터들의 통계를 내야하는 경우가 발생했다. 기본적으로는 주소데이터를 컬럼으로 추가하고, 같은 지역으로 GroupBy를 하여 통계를 내는 방식을 사용하지만,이렇게 주소데이터 컬럼을 사용하게되면,군, 시, 도로 확장해나갈때, 쉽게 그룹핑을 하기가 애매해진다.군,시,도에 따른 주소컬럼을 모두 포함하도록 쿼리를 만들어야하지만,해당 주소 컬럼에 포함되는 지역데이터가 엄청나게 많이 존재하기 때문에 난감해진다. Mysql에는 R-tree를 이용한 위치기반 인덱스를 사용할수있는 기능이 있지만,사용하는 PostgreSql에는 디플리케이트가 되었고,GiST인덱스가 그 자리를 차지하고 있었다.어차피 개념은 비슷하지! 개념은 2차원 좌표 데이..
[개발생각] 앱에서 한페이지에서 API를 많이 호출할때 튜닝 프로젝트의 막바지(?)에 프론트와 서버간의 API호출에 대한 튜닝을 한참했다. 여기서 아이디어가 하나 떠올랐다! 프론트와 서버간의 API호출을 튜닝을 진행할때 진행한 내용은 아래와 같다. 1) API를 중복하여 호출하는 부분은 줄인다.2) A API와 B API의 응답이 포함관계에 있는지 확인하고,포함하는 API 하나만 호출하도록 줄인다.3) A,B,C API를 하나의 묶음 API로 내려줄수있다면, 신규 API에 A,B,C 응답을 함께 내려주게하여, API호출을 줄인다.4) 한화면에서 여러개의 무거운 API를 호출해야할때, API의 호출을 줄인다. 4번이 이번에 이야기할 내용이다.1) 2) 3)번에 해당이 되지않고, 필연적으로 한화면에서 여러개의 API를 호출해야하는경우, 특히 차트나 그래프, 통계 데..
[개발생각] API와 앱의 출시 마무리 작업 프로젝트의 마무리시 꼭 해야하는 작업이 있다. 바로 폴리싱작업이라고 해야하나?! 개발중일때, 특히 프로젝트의 마무리시점까지는 엄청나게 바쁘다.우선 일정을 맞춰야하고, 그에따른 미진한 개발을 진행해야하기 때문이다.따라서, 여러 멤버들은 엄청나게 바쁘고,그에따라 이 기간에는 서로간의 커뮤니케이션이 현저하게 낮아지게 된다.(사실 이건 명약이 없다...) 물론, 이 현상이 잘못된 현상이긴하지만, 자연적인 현상이기도 하다고 생각한다.(훌륭한 프로젝트 멤버들이나, 아니거나, 빅테크나 아닌 조직이나, 동일하게 나타나는 현상같으니..사람이 하는일에서는 나타나는거 같다가 맞을듯? ㅋ) 이건 어디서나 필연적으로 나오는 현상같다. 잘못된것이라고는 생각하지 않는다는 말이다. 그런데, 멤버간의 커뮤니케이션이 줄어들어게되면, 소..

티스토리툴바