Pop your eXperience. Share It.
해당 코드는 Github를 확인해주세요. JPA를 이용해서 Paging API를 만들어 보도록 하겠습니다. 페이징 처리는 거의 모든 웹 개발에서 사용하고 있습니다. 그렇게 복잡하고 어려운 구현은 아니나 실제 쿼리로 작성할 때는 상당히 번거로운 작업이 됩니다. 또 데이터베이스마다 페이징 쿼리가 조금씩 다르다는 점도 복잡도를 높이는 요인 중 하나입니다. Spring Data JPA에서는 이러한 문제를 아주
필자는 도메인 주도 설계Domain-Driven Design(이하 DDD) 빌딩 블록Building blocks[1]으로 애플리케이션을 구현하면서 엔티티ENTITY[2] 마다 리파지토리REPOSITORY를 만드는 것을 자주 보았는데 자세히 살펴보면 여러 엔티티를 묶어서 하나처럼 사용하는 경우가 대부분이었다. DDD에서는 이러한 연관 객체의 묶음을 애그리게잇AGGREGATE이라고 정의하고 애그리게잇에 포함된 특정 엔티티를 루트Root 엔티티라고 부른다. 그리고 리파지토리를 만들 때
처음으로 공개 블로그인 Popit에 글을 올려봅니다. 단어나 표현이 조금 부족하더라도 너그러운 마음으로 읽어 주세요. 감사합니다. 초고속 인터넷망의 지속적인 확산과 모바일 환경이 빠른 속도로 진화를 거듭해왔지만, 고해상도 디지털 비디오를 인터넷으로 전송하는 작업은 항상 품질에 대한 확신을 할 수 없는 어려운 일이다. 최근 VoD(Video-on-Demand) 사업의 경쟁이 치열해지다보니 라이브 비디오
커머스 혹은 유통 도메인 설계에 대한 연작 내용 중에서 아래 그림이 있습니다. 그림에 대한 설명으로 계층이란 표현을 썼지만, 그림 자체에는 계층에 대한 어떤 내용도 없습니다. 연작이기 때문에 뒤에 쓴 다른 글에 계층을 왜 두었는지 설명이 있을 뿐입니다. 그림만보면 상품이라고 불리는 같은 개념을 구분해보고, 각각을 Product와 Item이라고 불러보자고 결정한 사항이라 할
얼마 전에 객체 모델링 공부하게 책 하나 추천해주세요를 쓴 탓인지 동료의 작업에 댓글[1]을 달다가 문득 모델링이란 개념에 대한 생각에 빠졌다. 벤 다이어그램을 왜 그리는가? 동료에게 왜 저런 제안을 했을까? 목적은 두 가지다. 하나는 작업 내역을 읽다 보니 아직 하려는 일의 초점이 불분명한데, 성급하게 코딩부터 하려는 동료 개발자를 돌려
정말 오랜만에 글을 쓰는 것 같습니다. 한번 쓰지 않기 시작하다 보니 이렇게까지 늘어졌네요;; 최근에 카프카 운영과 관련해 어드민 페이지 개선 작업을 했고, 워크 큐(work queue)로 카프카를 활용하여 프로세스를 개선한 과정과 느낀 점을 공유하고자 합니다. 배경 현재 전사 공용 카프카를 운영하면서, 필요한 어드민 페이지 일부는 제가 직접 만들어서 사용하고
커머스 혹은 유통 도메인 설계에 대한 연작 (지난 글) 1편. 커머스 혹은 유통 도메인 설계에 대한 연작 2편. 상품 정보 관리 라이브사이클 정의 필자의 유통 8년 경력 내내 관여한 모든 회사에서 정비하지 않고[1] 쓰는 기능이 있었다. 보통 프로모션이라고 부르는 바로 가격 할인 기능이다. 왜 그런가 답을 낼 수는 없다.
내가 생각하는 캡슐화란 (1)... 해당 코드는 Github에 공개되어 있습니다. 객체지향 개념에서 캡슐화는 정말 중요한 개념이라고 생각합니다. 캡슐화를 잘 지켜야 클래스 간의 결합도를 낮추어 코드를 유지 보수하기 쉽게 합니다. 이미 수많은 책이 이 개념에 관해서 설명하고 있습니다. 글을 읽을 때는 이해되지만 정작 캡슐화 좋은 코드를 작성하는 것은 또 다른 영역입니다. 저와
역사는 반복된다. 올해도 어김없이 그 패턴이 돌아왔다. OOO 공부하게 책 하나 추천해주세요. 이틀 전에 즉흥적으로 답했던 내용을 글로 쓰면서 더 많은 분에게 전달을 시도한다. 결론부터 말하면 세 권을 추천했다. * 도메인 주도 설계이하 DDD중에서 빌딩 블록 관련 내용 * UML을 활용한 객체지향 분석 설계 중에서 1부 개념 * UML, 실전에서는 이것만 쓴다 DDD
커머스 혹은 유통 도메인 설계에 대한 연작 (지난 글) 1편. 커머스 혹은 유통 도메인 설계에 대한 연작 오랫동안 추적한 일이다. 생각으로는 금방 정리할 수 있는 내용이지만, 실제로 구현할 수 있도록 정의하는 일은 그와는 다른 일[4]이다. 여튼 또 기회가 왔다. 시작은 한 개발자가 엑셀 업로드 기능을 만들었는데, 동료 기획자가
올해 1월 초에 썼던 팝잇 글쓰기 경험 회고를 떠올리며, 이번에는 해가 가기 전에 정리를 해본다. popit 편집자 제안을 받고 다시 시작한 블로그 쓰기는 애초에 목적이 있지 않았다. 과거에 오랜 블로깅을 했던 습관과 다년간 쉰 탓[1]이 어우러져 그저 쓰고 싶은 욕구를 분출하는 시간을 돌아본 것이 지난 팝잇 글쓰기 경험
프로젝트 수행 중에 시도해 본 내용 중 프로세스 품질 향상으로 진행한 내용을 정리해 보았습니다. 기술 이야기는 아니고, 프로젝트 운영과 협업을 효과적으로 이끌어 내 보려던 내용입니다. 간단하지만 효율적이였던 본 사례를 응원해 준 동료가 있어서 내용을 정리해 봅니다. 그 동료는 작고 시맨틱한 리소스[1]로 효율적이고 효과적으로 작업하기를 좋아합니다. 프로젝트 현황판이란? 프로젝트를