이전 글에서 세 가지 오해를 다뤘다."객체는 현실에 존재하는 것만 객체다" → 규칙을 소유할 책임이 있는가로 판단한다"Service는 전부 가짜 객체다" → 도메인 규칙과 유스케이스 흐름이라는 서로 다른 책임이 있다"Rich Domain이면 동시성도 해결된다" → 도메인 규칙의 소유권과 동시성 제어의 원자성은 별개의 책임이다세 가지를 관통하는 패턴은 "경계를 너무 좁게 그으면 깨진다"였다.이번 글에서는 두 가지를 더 다룬다. 도구에 대한 오해와, 패턴에 대한 오해. 오해 4: "좋은 ORM, 자동으로 좋은 설계" 내가 처음 믿었던 생각Prisma에서 도메인 로직을 Entity에 넣기 어렵다는 걸 느끼고,"Data Mapper 패턴의 ORM을 쓰면 자연스럽게 Rich Domain이 되겠지"라고 생각했다...

ADR(Architecture Decision Record) ? 더 나은 설계를 위한 밑거름 작업은 ..? 1. 들어가며: "코드 리뷰 시간에 줄바꿈을 논의하고 있을 필요가 있을까 ?"현재 팀의 백엔드 시스템은 MSA(마이크로서비스 아키텍처) 및 역할에 따라 여러 개의 레포지토리로 나뉘어 운영되고 있습니다.신규 피처를 개발하며 여러 레포지토리를 다루다 보니 한 가지 큰 문제점을 발견했습니다. 다른 글에서도 언급했지만 .. 바로 레포지토리마다 TypeScript, ESLint, Prettier 설정이 파편화되어 있다는 점이었습니다.이로 인해 다음과 같은 비효율이 매일 반복되고 있었습니다.리뷰 리소스 낭비: PR(Pull Request) 리뷰 시, 본질적인 비즈니스 로직이나 아키텍처에 대한 논의보다 코드 스..

"조직의 개발 문화와 배포 파이프라인의 안정성을 근본적으로 끌어올리는 아키텍처 설계도란 .." 미래에 있을 장애를 조기에 예방하려면 ..시스템 레벨의 관점(릴리스 엔지니어링, 점진적 롤아웃, 장애 예방)에서 고민해 볼 필요가 있을 것 같다고 생각합니다. 다중 레포지토리(Polyrepo) 정적 분석 환경 표준화 및 점진적 도입기입니다 !! 1. 들어가며: "왜 레포지토리마다 코드 리뷰 기준이 다를까 ?"현재 팀의 백엔드 시스템은 역할에 따라 여러 개의 레포지토리(API 서버, 게이트웨이, 서버리스 함수 등)로 나뉘어 서비스되고 있습니다.어느 날 신규 피처를 개발하며 여러 레포지토리를 오가던 중, 한 가지 의문이 생겼습니다. "A 서비스에서는 에러를 뱉는 코드가, 왜 B 서비스에서는 정상적으로 통과되어 배포..

"과연 DB에 failed_notifications 테이블을 만들고, 실패한 알림을 이곳에 INSERT한 뒤 기존 notifications 테이블에서 DELETE 처리하는 것이 최선일까?"프로젝트를 진행하며 알림 발송 실패 처리에 대해 고민하게 되었습니다.보통 실패 처리를 논할 때"Redis의 지연 큐(Delayed Queue)를 쓰자" 혹은 "Kafka의 DLQ(Dead Letter Queue)를 쓰자"라고 결론을 내리기도 합니다.하지만 무턱대고 새로운 인프라를 추가한다는 것은관리 포인트 증가, 그리고 새로운 장애 전파 가능성의 증가를 의미하기도 합니다. 그래서 이번 글에서는 새로운 써드파티 인프라(Kafka, Redis 등)에 기대지 않고,현재 가진 기술(Spring, Java, MySQL, OS)을..

간단히, 또 오랫동안, 고민해 왔던 생각 .. 그래서 어떻게 도메인을 왕으로 만드는데 ? — 좋은 객체 지향을 향하는 나름의 규칙도메인을 왕으로 만드는 것이 OOP, 그것이 DDD. 이 글을 쓰는 이유객체 지향을 공부하고, DDD를 흉내 내보고, 실제 프로젝트에 적용하면서 몇 가지 "그럴듯한 기준"을 세웠다. 처음에는 꽤 잘 먹혔다. 그런데 규모가 커지고, 코너 케이스를 만나고, 부하 테스트를 돌리면서 그 기준들이 하나씩 깨졌다.이 글은 내가 믿었던 것들이 어디서 깨졌고, 지금은 어떤 기준으로 바뀌었는지를 정리한 회고다. 정답이 아니라 "지금의 기준선"이다. 앞으로도 계속 깨지고 다듬어질 것이다.다루는 오해는 세 가지다 (더 많아질 수도 있음):객체는 현실에 존재하는 것만 객체다Service는 전부 ..

"이제 매번 프롬프트를 길게 작성하는 '프롬프트 엔지니어링'의 시대가 끝나고,AI 에이전트의 행동을 구조화하는 '실행 설계(Execution Design)'의 시대로 넘어왔다"라고 Claude(와 관련된 작업자들)는 말합니다 .. 점차적으로 기술적 패러다임에 있어서 계속되는 변화는 끊이지 않을 것 같네요 .. 클로드 공개 파일 분석 내용입니다 !pdf 링크1. '스킬(Skill)'이란 무엇인가요?스킬은 클로드(Claude)에게 "특정 업무나 반복되는 워크플로우를 어떻게 처리해야 하는지"를 가르쳐주는 '지침서 패키지'입니다.과거에는 대화창에 "너는 백엔드 개발자야. 우리 프로젝트의 디자인 규칙은 이렇고, 코드는 이렇게 짜야 해..."라고 매번 길게 입력해야 했습니다. 하지만 스킬을 사용하면 이런 규칙, 템..

VS Code에서 IntelliJ의 ⌘B = Go to Declaration or Usages 직접 구현해 보기IntelliJ를 오래 쓰다가 VS Code로 넘어오면서 가장 먼저 어색해지는 것 중 하나가 네비게이션이었다. 특히 ⌘B.IntelliJ에서는 ⌘B 하나로 꽤 자연스럽게 움직인다.호출부에서는 선언/정의로 이동하고,이미 선언 위치에 있으면 usages를 보여준다반면 VS Code는 기본적으로 이 기능이 분리되어 있다.Go to DefinitionGo to DeclarationFind ReferencesPeek Referencessettings 와 keybindings 조합만으로는 IntelliJ의 Go to Declaration or Usages 를 완전히 복제하기 어렵다.그래서 이번에는 아예 V..

비대해진 Service의 한계 — 도메인 분리를 위한 ORM 패러다임 시프트서론: GraphQL이 해결하지 못한 것GraphQL이 가져다준 유연함 — 오버페칭/언더페칭 해소, 클라이언트 주도의 데이터 선언, AST 파싱을 통한 Resolver 라우팅 — 을 다뤘었다.하지만 GraphQL은 백엔드 내부의 구조적 문제까지 해결해주지는 않는다.오히려 GraphQL의 유연함 이면에서, 조용히 커지고 있던 문제가 하나 있었다. Service 계층의 비대화다.이 글은 Prisma 중심의 스키마 기반 설계가 왜 "Fat Service"를 만들어내는지,그것이 이벤트 기반 아키텍처(EDA) 전환에 어떤 발목을 잡는지,그리고 Data Mapper 패러다임의 ORM으로 어떻게 돌파구를 찾으려 하는지를 정리하려는 글이다. ..