Pop your eXperience. Share It.
동료 유영모가 ID로 다른 애그리게잇을 참조하라에서 애그리게잇을 본문에서 조립물로 바꾼 사연에 대한 이야기다. 두레이로 popit 글 검토를 하는 우리회사 popit 글 검토는popit 저자들이 글을 쓰는 워드프레스 시스템 상에서 벌어진다. 그런데, 사내에서 쓰는 두레이로 우리끼리 대화를 하고 싶어서 회사안에서는 채널을 만들었다. 워드프레스는 결과물 편집은 좋지만, 의견을 주고 받기는 어려우니까. 그러던 차에
필자는 지난 글 전반부에서 도메인 주도 설계Domain-Driven Design에서 말하는 구조물 중 하나인 조립물AGGREGATE[1]에 대해 이야기했다. 조립물을 구현하다 보면 다른 조립물을 참조해야 할 때가 있다. 이를 구현하는 방식은 크게 조립물의 루트 엔터티Root Entity 객체를 참조(포인터) 하는 것과 식별자로 어디서든 쓸 수 있는 값을 사용하는 방법(ID)이
(이미지 - https://aws.amazon.com/emr/features) AWS EMR 은 정말 좋은 툴입니다. (가격만 안비싸고 좀만 더 빨리 뜨면) * 버튼 눌러서 쉽게 만들 수 있고 * Spark, Presto, Flink 등 설치된 클러스터에 필요한 Job 만 던지면 되고 * Zeppelin, Jupyter 등 탐색을 위한 도구도 바로 사용할 수 있습니다. 늘 그렇듯이 해보니 된다
애초에 이글은 동료에게 시스템 맥락도[1]Context diagram를 설명하며 쓰던 글인데 독자 타겟을 바꿔 포괄적으로 시스템을 둘러싼 오해를 드러낼 목적으로 고쳤다. 시스템은 사용자를 포함하는가? 시스템 맥락을 그리는 일은 20년 가까이 해오던 일종의 틀에 박힌 일이다. 그런데, 배경 지식이나 경험 없이 처음으로 그려보려고 질문하는 동료를 만나는 순간 새삼 없던 흥미가 솟아나는
해당 코드는 Github를 확인해주세요. Spring Guide 1. Test 전략 가이드 2. Exception 전략 가이드 3. Domain 객체 가이드 4. 외부 API 가이드 5. Service 적절한 크기 가이드 Exception Guide 스프링은 예외처리를 위해 다양하고 막강한 어노테이션을 제공하고 있습니다. 일관성 있는 코드 스타일을 유지하면서 Exception을 처리하는 방법에 대해서 소개하겠습니다. 통일된 Error Response
제목에 신경을 썼다. 이 글을 왜 쓰는지 생각해 보고 싶었고, 읽는 이에게 도대체 가치가 있을 수 있나 싶은 회의적인 마음이 들어 집중해서 선언해봤다. 여러 권을 함께 읽는 병렬 독서 습관 군대 동기가 사물함에 책을 여러 권을 두기에 '그걸 다 읽냐'고 물었던 기억이 있다. 자신은 동시에 여러 권을
페이스북에 간단한 독후감을 쓰고도 아쉬워서 블로그 글로 남긴다. 먼저 이 책이 읽어볼만한 가치가 있느냐 묻는다면 '그렇다' 라고 답할 것이다. 묻는 대상이 주로 역사학자나 역사에 깊은 관심이 있는 사람이 아니라면 말이다. 한국판 역사란 무엇인가 누군가에게 한 줄로 소개하라면, 이책은 한국판 <역사란 무엇인가>라고 소개할 수 있다. 물론,
해당 코드는 Github에 공개되어있습니다. Spring Guide 1. Test 전략 가이드 2. Exception 전략 가이드 3. Domain 객체 가이드 4. 외부 API 가이드 5. Service 적절한 크기 가이드 스프링은 다양한 테스트 전략을 제공하고 있습니다. 대표적으로 Slice Test 라는 것으로 특정 레이어에 대해서 Bean을 최소한으로 등록시켜 테스트 하고자 하는 부분에 최대한 단위
연휴[1]를 마치고 출근해서 처음으로 머리써서 처리한 일은 동료 개발자가 두레이에 남겨 놓고 간 작업입니다. 필자가 먼저 서울에 갔을 때 북경에 남아 있던[2] 그가 갱신한 작업 내용을 보고, 필자가 '무얼 더 개선할 수 있을까?' 생각하는 일입니다. 그가 나에게 작업을 요청한 것이 아니라 우리가 서로 나눴던 의견을
해당 코드는 Github를 확인해주세요. Repository Code public interface AccountRepository extends JpaRepository<Account, Long>, AccountCustomRepository { Account findByEmail(Email email); boolean existsByEmail(Email email); List<Account> findDistinctFirstBy... @Query("select *from....") List<Account> findXXX(); } JpaRepository를 이용해서 복잡한 쿼리는 작성하기가 어려운점이 있습니다. findByEmail, existsByEmail 같은 유니크한
해당 코드는 Github를 확인해주세요. step-12: 페이징 API 만들기 에서 JPA와 Pageable를 이용해서 간단한 페이징 API를 만들었습니다. 이번 포스팅에서는 Query Dsl 동적 쿼리를 이용해서 검색 페이징 API를 만들어 보겠습니다. 기초 작업 Maven을 기준으로 설명드리겠습니다. 아래의 코드를 pom.xml에 추가하고 mvn compile을 진행합니다. <dependency> <groupId>com.querydsl&
첫 연재에서 소개한 개념 정제 후에 동료 개발자가 해당 내용 구현에 나섰습니다. 두 계층으로 나누어 연결한 상품 개념 이전에 그린 그림을 조금 수정해서 상황에 대한 설명을 보강합니다. Product와 Item 개념 사이에 그린 두 가지 관계를 동료 개발자가 구현한 것이 아닙니다. 그래서, 둘 사이를 연결하는 Catalog 개념을 추가하여, 그의 구현을 Catalog