자라나기

도메인 주도 개발 시작하기가장 쉽게 배우는 도메인 주도 설계 입문서. 도메인 주도 설계(DDD)를 처음 배우는 개발자를 위한 책이다. 실제 업무에 DDD를 적용할 수 있도록 기본적인 DDD의 핵심 개념을 익히고 구현을 통해 학www.aladin.co.kr (책에 있는 문장이 아닐 수 있음... 편집 있을 수 있음...)        Chapter 1. 도메인도메인 = 해결하고자 하는 문제 영역전문가나 관련자가 요구한 내용이 항상 올바른 것은 아니며 때론 본인들이 실제로 원하는 것을 정확하게 표현하지 못할 때도 있다. 대화를 통해 진짜로 원하는 것을 찾아야 한다.도메인에 따라 용어 의미가 결정되므로 도메인마다 각각의 다이어그램에 모델링해야 한다.처음부터 완벽한 개념 모델을 만들기보다 전체 윤곽을 이해하는 ..

테스트 > 테스트를 통과할 만큼의 코딩 > 리팩토링 > 테스트 테스트를 통과시킬 만큼의 기능을 구현한다. 아직 추가하지 않은 테스트를 고려해서 구현하지 않는다. 첫 번째 테스트는 가장 쉽거나 가장 예외적인 상황을 선택한다. 첫 번째 테스트로 만들어야 할 코드가 길어지면 구현을 다 하고 테스트를 하는 방식과 다르지 않다. 테스트 코드도 코드이기 때문에 유지보수를 해야 한다. 각 테스트 메서드에서 발생하는 중복을 알맞게 제거하거나 의미가 잘 드러나도록 수정한다. 중복을 제거한 뒤에 오히려 테스트 코드 관리가 어려워진다면 제거했던 중복을 되돌려야 한다. TDD를 시작할 때 테스트할 목록을 미리 정리하면 좋다. 그 중 어느 테스트가 구현이 쉬울지, 또는 어느 테스트가 예외적인지 생각해본다. 범위가 큰 리팩토링은..

사용자를 위한 API 디자인하기 프로바이더가 아닌 컨슈머의 입장에서 디자인한다. 데이터 모델을 그대로 노출하지 않는다. e.g. 테이블이 2개라고 api를 2개 제공하거나, 이해하기 어려운 데이터 이름을 그대로 사용하기 No! 비즈니스 로직을 그대로 노출하지 않는다. e.g. 고객 주소를 가져와서, 주소를 수정하고, 새주소 추가 api들을 제공하는 대신(이는 비즈니스 로직을 컨슈머에게 위임하는 것이며, 컨슈머가 api 사용을 깜빡할시 치명적 문제가 될 수 있다), 고객 주소 수정 api 하나만 제공하기 소프트웨어 아키텍처를 그대로 노출하지 않는다. e.g. 상품 정보와 상품 가격이 다른 시스템에서 처리된다고 상품 검색, 상품 가격 조회 api 2개를 제공하기 No! API를 디자인할 때 질문하기 누가 사..

전통적인 프로젝트 수행 방식의 한계 프로젝트 초기에 구체적인 요구사항을 도출하기 어렵다. 프로젝트 중간에 발생하는 요구사항의 변경을 반영하기 어렵다. 프로젝트 과정 중 중간 문서 산출물이 많이 요구되어 개발 업무가 지연된다. 프로젝트 관리자 중심의 명령과 통제 방식때문에 구성원은 수동적으로 바뀌고, 커뮤니케이션이 부족하다. 애자일 소프트웨어 개발 선언문의 중심 내용 프로세스와 도구보다는 개인과 개인 간의 상호작용에 더 큰 가치를 둔다. 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다. 계약 협상보다는 고객과 협력에 더 큰 가치를 둔다. 계획을 따르기보다는 변화에 대응하는 것에 더 큰 가치를 둔다. 애자일 소프트웨어의 개발 원칙 12가지 소프트웨어 개발의 최우선 목표는 빠르고 지속적으로 가치 ..

책장 정리 중 ··· 메모해놨던 부분을 여기로 옮긴다. 조영호, 위키북스 No object is an island. 협력은 요청과 응답으로 구성된다. 협력하는 과정 속에서 객체는 역할을 부여받아 어떤 행동을 할 책임을 가진다. 중요한 것은 어떤 클래스가 필요한가가 아니라 어떤 객체들이 어떤 메시지를 주고받으며 협력하는가다. All the objects have a state(상태), behavior(행동) and identity(식별자). 상태란 특정 시점에 객체가 가지고 있는 정보의 집합이다. 객체는 자율적인 존재임으로 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다. 행동이란 외부의 요청 또는 수신된 메세지에 응답하기 위해 동작하고 반응하는 활동이다. 객체가 외부에 노출하는 것은..

DDD (Domain Driven Design) 소프트웨어가 복잡한 것은 도메인이 복잡하기 때문이다. 그래서 도메인 전문가(기획자)와 개발자가 어떻게 협업하느냐가 중요하다. 이를 위해 보편언어를 사용하고, 모델 주도 디자인을 해야 한다. 단순히 Entity, value object, aggregate와 같은 구체적 개념이라기보단 개발 프로세스에 대한 철학이다. step1. 보편언어 정의 도메인에 대한 어휘를 이해관계자(기획자, 개발자, 분석가 등등)들이 공통적으로 이해할 수 있도록 정의한다. step2. 모델 주도 설계 도메인 분석과 설계의 간극은 최소화한다. 분석/설계/구현의 모든 단계를 관통하는 하나의 모델을 유지한다. 모델 = 코드 도메인이란? 영역, 집합 비즈니스 Domain 예를 들면 주문, 고..

린 소프트웨어 개발 방법론은 소프트웨어 개발 과정에서 불필요한 낭비 과정을 제거하고 신속하게 고객에게 가치를 전달하는 것을 목표로 한다. 이를 위해 개발, 통합, 테스트, 문서화, 배포까지 하나의 흐름을 빠르게 진행한다. 이는 한 번에 처리하는 작업량을 작게 구성해 반복적으로 개발함을 의미한다. 린 개발 방법론은 1940년대 제조 업체에서 등장하여, 생산 비용은 대량 생산에서와 같이 낮게 유지시키면서 생산량은 줄여 품질을 향상시키는 역할을 하였다. 신고 시게오는 제조 7대 낭비를 정의했고, 이를 소프트웨어 개발에도 적용해볼 수 있다. 1. 미완성 작업 Partially Done Work 설계 및 요구사항 문서는 있지만 코드로 구현되지 않은 작업 설계 및 요구사항이 오래될수록 변경될 가능성도 커진다. 고객..

리액티브 프로그래밍 지금까지 흔히 사용했던 리스트(List)와 같은 컬렉션은 이미 데이터가 '생성'되어 있습니다. 하지만 리액티브 프로그래밍에서는 '데이터가 통지될 때마다' 프로그램이 '반응'하여 데이터를 처리합니다. 이러한 데이터의 흐름을 데이터 스트림이라고 하며, '앞으로 생성될지도 모르는 데이터'까지도 포함하는 개념입니다. 쇼핑몰을 기존의 방식대로 만들자면, (주문 발생 -> 주문쪽에서 상품 재고 변경 호출)이 수행될 것입니다. 리액티브 프로그래밍에서는 (주문 발생 -> 상품쪽으로 상품 재고 변경 데이터 전달 -> 상품쪽에서 상품 재고 변경)이 수행됩니다. 객체의 책임이 달라지는 것이죠. 주문쪽은 데이터 전달까지만 책임지고 그 데이터로 상품쪽이 무엇을 하든 상관하지 않습니다. 이런 방식의 장점은 무..

JUnit 5 User Guide Although the JUnit Jupiter programming model and extension model will not support JUnit 4 features such as Rules and Runners natively, it is not expected that source code maintainers will need to update all of their existing tests, test extensions, and cus junit.org JUnit5는 3가지 모듈로 구성되어 있다. JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage JUnit Platform : JVM에서 테스트 프레임..