책/도메인 주도 설계 철저 입문

[도메인 주도 설계 철저 입문] 12. 도메인의 규칙을 지키는 "어그리게이트"

어그리게이트란? 여러 객체가 모여 한가지 의미를 갖는 하나의 객체가 될 때, 이를 어그리게이트라고 할 수 있다. 어그리게이트는 경계와 루트를 갖는다. 루트는 어그리게이트 내의 특정한 객체인데, 외부에서 어그리게이트를 다루는 모든 조작은 루트를 거쳐야만 한다. 어그리게이트에 포함되는 객체를 외부에 노출하지 않음으로써 객체를 안전하게 다룰 수 있다. 객체를 다루는 기본 원칙 질서 없이 어그리게이트 내의 객체들을 다루게 되면, 객체의 논리적 일관성을 유지하기가 어렵다. UserName userName = new UserName("gildong"); user.name = userName; // 바람직하지 않은 변경 시도 user.changeName(userName); // ok 위와 같이 사용자의 이름을 변경 ..

[도메인 주도 설계 철저 입문] 10. 데이터의 무결성 유지하기

무결성이란 : 정보가 서로 모순이 없고 일관적이라는 뜻. 무결성 위배되는 경우 : 사용자 중복 검사를 시행할 때, 사용자 A 가 회원 등록 시도 => 중복 검사 => 중복되지 않음! (사용자 A 의 회원 등록이 db 에 적용되기 전) 사용자 B 가 동일한 회원 등록 시도 => 중복검사 => 중복 안됨! 사용자 A 의 회원 정보 저장 사용자 B 가 A와 동일한 회원 정보 저장 데이터 무결성을 지키는 방법 1. 유일 키 제약 : 가장 강력한 수단이지만, 코드 상으로 드러나지 않고 비지니스 코드가 db 에 의존적이라는 단점이 존재. 트랜젝션과 함께 사용하는 것이 좋다. 2. 트랜젝션 1. db 트랜젝션 객체 이용 : 아래 코드는 트랜잭션 코드를 통해 무결성을 확보한다. 하지만 이 경우에는 인프라 객체인 con..

[도메인 주도 설계 철저 입문] 7. 의존 관계 제어

1) 의존이란 무엇인가? (1) ObjectA 가 ObjectB 에 의존하는 관계의 예 public class ObjectA { private ObjectB objectb; } ObjectA 는 ObjectB 를 참조한다. 다시말해 ObjectB 가 없으면 ObjectA 는 정의될 수 없다. 이 때 ObjectA 가 ObjectB 에 의존한다고 한다. (2) 구현체가 인터페이스에 의존하는 관계의 예 public interface UserRepository { User find(UserId id); } public class UserRepositoryImpl implements UserRepository { @Override public User find(UserId Id) { (...생략...) } } ..

[도메인 주도 설계 철저 입문] 6. 어플리케이션 서비스 - 도메인 서비스와의 분리!

이 글을 읽고 깨달아,, 적용한 커밋. 아래 PR 중에 있다. [refactor/member] 회원 서비스 리팩토링 by Dong-Hyeon-Yu · Pull Request #94 · InhaBas/Inhabas.com-api 학년 정보 없애기 학기 -> 기수 중복검사로직을 도메인 영역으로 분리 (링크) 회원가입 서비스 리팩토링 회원종류 생성 #93 회원가입 가능 기간 및 인터뷰 기간 db 설정 기능 추가 팀 생성 #77 resolve github.com 이 책에서 말하는 서비스는 크게 두가지로 나뉘는 듯 하다. 하나는 도메인 서비스, 다른 하나는 어플리케이션 서비스. 도메인의 특성에 관한 활동은 도메인 서비스. 클라이언트에게 제공할 UseCase 에 대한 활동은 어플리케이션 서비스. 기존에는 layer..

[도메인 주도 설계 철저 입문] 5. 레파지토리 - 데이터와 관계된 처리를 분리하자

프로그램을 실행할 때, 메모리에 로드된 데이터는 프로그램을 종료하면 그대로 사라져버린다. 특히 엔티티는 생애주기를 갖는 개체이기 때문에 프로그램의 종료와 함께 사라지면 안된다. 이를 위해서는 데이터를 데이터스토어에 저장하고 불러올 수 있어야한다. 데이터스토어로부터 불러오고, 저장하는 등의 행위를 추상화한 객체가 레파지토리 객체이다. 레파지토리의 역할과 책임 이 레파지토리 객체는 도메인 개념으로부터 유래한 것이 아니라, 기술적 문제를 해결하기 위해 탄생한 객체이다. 따라서 도메인을 잘 서술한 코드를 헤집어놓지 않으면서, 기술적 코드를 잘 분리해는 역할을 담당한다고 볼 수 있다. 특히 특정 db 에 의존적일 수 밖에 없는데, 이 때문에 더 다루기 까다롭게 되는 코드가 되어버릴 때가 많다. 그래서 레파지토리 ..

[도메인 주도 설계 철저 입문] 4. 도메인 서비스 - 부자연스러운 도메인 객체의 행동을 맡기자

값 객체나, 엔티티 같은 도메인 객체에는 객체의 행동읠 정의할 수 있다. 예를 들어 사용장명으로 사욯라 수 잇는 문자열의 길이나 문자의 종류에 제한이 있다며 ㄴㅇ이런한 지식은 사용자명을 나타내는 값 객체에 정의할 수 있다. 근데 시스템에는 도메인 객체로 구현하기 어색한 행동도 있다. 도메인 서비스는 이런 어색함을 해결해주는 객체다. 예를 들어 사용자 이름 중복 여부 기능을 추가한다고 하자. 이 코드를 User 라는 도메인 객체에 추가하게 된다면 아래와 같이 할 수 있다. class User { private UserId id; private UserName name; public User(Integer id, String name) { if (Objects.isNull(id) || Objects.isNu..

[도메인 주도 설계 철저 입문] 3. 엔티티 - 생애주기를 갖는 객체

도메인 주도 개발에서 말하는 엔티티는 도메인 모델을 구현한 도메인 객체를 의미한다. 이전 장에서 다뤘던 값 객체도 도메인 객체를 의미한다. 값 객체와 엔티티의 차이점 값 객체와 엔티티의 차이점은 "동일성"을 식별할 수 있는지에 달려있다. 예를 들어 값 객체는 이름, 학년 등의 특정 성질을 띄는 값을 캡슐화한 것이라면, 엔티티는 회원을 예로 들 수 있다. 값 객체는 변하지 않는 값이고 (수정이 아닌 새로 생성, premitive type 을 예로 들면 쉬울 듯) 엔티티는 수정 가능하다. 또 속성이 같아도 다른 엔티티일 수 있는데 예로 같은 이름값이어도 다른 사람일 수 있는 것처럼 말이다. 따라서 엔티티를 식별할 수 있는 고유필드가 필요한데, 사람의 경우는 주민등록번호 등이 될 수 있다. 개발을 할 때, 이..

[도메인 주도 설계 철저 입문] 2. "값 객체"의 개념 & 적용 예시

흔히 프로그램을 작성하다보면, 사용자의 이름이나 나이 등을 원시타입(String, int) 등에 그대로 저장하는 경우가 있는데, 이런 경우에는 해당 값의 특성을 제대로 나타낼 수 없다. 이것은 여러 개발자가 함께 작업할 때 그 단점이 명확하게 나타나는데, 만약 String name 이라고 했을 때, 이름 값이 성과 이름을 포함하는 이름인지, 한국인 이름만 포함하는 이름인지 알 수 없기 때문에, db 를 조회해서 기존 data 가 어떤 식으로 저장되어 있는지 조회해야하는 등의 불편함이 있다. 따라서 원시타입을 그대로 사용하는 것이 아니라 해당 특성 값을 잘 나타낼 수 있도록 하면서, 동시에 유효성 검사도 진행할 수 있는 "값 객체"를 활용하는 것이 좋다. 값 객체를 도입했을 때의 장점 표현이 분명해진다. ..