![연관의 방향성
• 방향성의 종류
– 단 방향: 두 객체 중 한 객체만 레퍼런스 가짐
– 양 방향: 두 객체가 서로에 대한 레퍼런스 가짐
• 양 방향 예
emp1:Employee org1:Oragnization rule1:Rule
organization=org1 employees = [emp1, emp2]
rule = rule1
emp2:Employee
organization=org1
7](https://image.slidesharecdn.com/dddfinal-120118045136-phpapp02/85/DDD-Final-7-320.jpg)
![객체의 라이프사이클
• 객체 생성 - 사용 - 소멸
– 동일 라이프사이클을 갖는 객체들의 군 존재
emp1:Employee org1:Oragnization rule1:Rule
organization=org1 employees = [emp1, emp2]
rule = rule1
emp2:Employee
organization=org1
org1이 삭제되면
rule1도 삭제
org1이 삭제되도
emp2는 삭제 안 됨
12](https://image.slidesharecdn.com/dddfinal-120118045136-phpapp02/85/DDD-Final-12-320.jpg)
![[수정본] 우아한 객체지향](https://cdn.slidesharecdn.com/ss_thumbnails/woowahan-oo-190624161343-thumbnail.jpg?width=560&fit=bounds)
![[112]rest에서 graph ql과 relay로 갈아타기 이정우](https://cdn.slidesharecdn.com/ss_thumbnails/112restgraphqlrelay-161023161032-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (20)
Viewers also liked (11)
Ad
Similar to DDD 구현기초 (거의 Final 버전) (20)
![[HaU] 신입 기술 면접 준비 java](https://cdn.slidesharecdn.com/ss_thumbnails/haujava-170411083050-thumbnail.jpg?width=560&fit=bounds)
Ad
More from beom kyun choi (20)
DDD 구현기초 (거의 Final 버전)
- 1. 짜친 세미나, DDD 쌩기초 이야기 - 거의 Final Version 최범균 ([email protected]) 자바캔 카페(http://cafe.daum.net/javacan) 자바캔 블로그(http://javacan.tistory.com)
- 2. TOC • 객체와 연관 – 객체와 연관 • DDD 쌩 기초 – 레이어 구성 – DDD 빌딩 블록 • DDD와 ORM • DDD 구현 이야기 – ORM 이용 구현하기 • 도메인 모델 구현 • 리포지토리의 구현 – 어플리케이션 레이어 서비스 구현 – UI 영역(컨트롤러) 구현 • 참고 자료 2
- 3. 객체와 연관 3
- 4. 객체란? 객체는 기능 제공 객체 객체 객체 객체 객체 객체 다른 객체를 사용 4
- 5. 클래스: 객체의 정의 • 기능을 public 메서드로 정의 – 데이터는 외부에 드러내지 않고 기능 정의만 제공 • getter/setter 메서드의 최소화 • 다른 객체를 사용하는 방법 – 필드를 이용해서 다른 객체를 레퍼런스로 참조 • 연관(Association)이라고 표현 – 메서드에서 필요한 시점에 객체를 생성해서 사용 5
- 6. 객체 간 연관의 예 필드 public class Employee { Organization org = new Organization(…); private String name; private Organization organization; Employee e1 = new Employee(…); ... Employee e2 = new Employee(…); public void setOrganization(Organization org) { this.organization = org; org.add(e1); } org.add(e2); } 필드 public class Organization { private String name; private List<Employee> employees; ... public void add(Employee emp) { this.employees.add(emp); emp.setOrganization(this); } } 6
- 7. 연관의 방향성 • 방향성의 종류 – 단 방향: 두 객체 중 한 객체만 레퍼런스 가짐 – 양 방향: 두 객체가 서로에 대한 레퍼런스 가짐 • 양 방향 예 emp1:Employee org1:Oragnization rule1:Rule organization=org1 employees = [emp1, emp2] rule = rule1 emp2:Employee organization=org1 7
- 8. 연관의 종류 • Many-To-One – 예, 다수의 Employee가 한 Organization과 연관 • One-To-Many – 예, 한 Organization이 다수의 Employee와 연관 – 콜렉션으로 구현: Collection, Set, List, Map • One-To-One – 예, 한 Oranization이 한 Rule과 연관 • Many-To-Many – 콜렉션 8
- 9. 모든 객체가 메모리 있다면… (1) • 연관된 객체들을 이용해서 기능을 구현 • 예1, Rule의 교체: 연관된 객체 교환으로 구현 Organization org = …; // 어딘가에서 구함 // Organization의 메서드 Rule newRule = new Rule(…); public void changeRule(Rule newRule) { org.changeRule(newRule); this.rule = newRule; } • 예2, 팀 이동: 양방향 연관을 처리 Organization org2 = …; // 어딘가에서 구함 // Employee의 메서드 Employee emp1 = …; // 어딘가에서 구함 public void transferTo(Organization org) { emp1.changeTeam(org2); Organization oldOrg = this.organization; this.organization = org; oldOrg.remove(this); } // Organization의 메서드 public void remove(Employee e) { employees.remove(e); } 9
- 10. 모든 객체가 메모리 있다면… (2) • 연관된 객체들을 이용해서 기능을 구현 • 예3, Rule의 확인: 연관된 객체를 구해 확인 Organization org = …; // 어딘가에서 구함 // Organization의 메서드 Rule rule = org.getRule(); public Rule getRule() { if (rule != null) { return this.rule; rule.check(someData); } } // Rule의 메서드 publiic void check(Data data) { … } • 예4, Rule의 확인: 내부적으로 위임 Organization org2 = …; // 어딘가에서 구함 // Organization의 메서드 org.checkRule(someData); public void checkRule(Data data) { if (rule == null) { return; } rule.check(data); } 10
- 11. 모든 객체가 메모리 있다면… (3) • 객체를 메모리에 보관/검색 위한 방법 필요 – 객체마다 고유 식별값 필요 • 메모리 상의 레퍼런스 이용은 한계 • 고유 식별 값을 갖는 객체를 Entity라 함 – 객체 보관하고 제공해주는 기능 필요 • DDD에서는 이를 Repository로 추상화 public interface OrganizationRepository { public void save(Organization org); public Organization findById(Integer id); } Organization org = organizationRepository.findById(id); org.checkRule(…); 11
- 12. 객체의 라이프사이클 • 객체 생성 - 사용 - 소멸 – 동일 라이프사이클을 갖는 객체들의 군 존재 emp1:Employee org1:Oragnization rule1:Rule organization=org1 employees = [emp1, emp2] rule = rule1 emp2:Employee organization=org1 org1이 삭제되면 rule1도 삭제 org1이 삭제되도 emp2는 삭제 안 됨 12
- 13. DDD 쌩 기초 13
- 14. DDD(Domain Driven Design) • 도메인 모델로부터 디자인하기 • 도메인 모델의 중요성 강조 – 도메인 모델을 최대한 설계에 반영 • 예, Ubiquitous Language (용어 최대한 반영) – 모델이 깨지지 않는 방법 제시 (일관성 유지) • 예, Bounded Context, Anticorruption Layer 등 • 이를 위한 기본 설계 기법 제시 – 레이어 구성 – 도메인 레이어의 기본 빌딩 블록 14
- 15. DDD 구현 위한 필수 쌩 기초 발췌: Domain Driven Design (Eric Evans) 15
- 16. Layered Architecture 사용자에게 정보 출력 User Intreface 사용자의 요청을 해석 하위 레이어에 전달 어플리케이션의 상태를 관리 / Thin Layer Application 비즈니스 로직/객체 상태를 포함하지 않음 실제 비즈니스 처리는 도메인에 요청 도메인에 대한 정보를 포함 Domain 비즈니스 객체의 상태를 포함 비즈니스 로직을 제공 다른 레이어를 위한 지원 라이브러리 Infrastructure 영속성 구현 16
- 17. 도메인 모델의 기본 구성 요소 • Entity • Value • Aggregate • Repository • Service 17
- 18. 도메인 모델의 기본 구성 요소, Entity • 주요 특징 – 모델을 표현 – 고유의 식별 값을 가짐 – 모델과 관련된 비즈니스 로직을 수행 – 자신만의 라이프 사이클을 가짐 • 예, 평가 시스템에서의 Entity – Employee(직원) – Organization(조직) 18
- 19. 도메인 모델의 기본 구성 요소, Value • 고유의 키 값을 갖지 않음 • 데이터를 표현하기 위한 용도로 주로 사용 – 개념적으로 완전한 데이터 집합 <<Entity>> – (주로) Immutable 임 Employee 자신에게 알맞은 로직을 제공 -id : Integer – -name : String – Entity의 속성으로 사용 -address : Address -organization : Organization • 자신의 라이프사이클을 갖지 않음 • 엔티티를 따름 1 • 예 – Address(주소) 1 <<Value>> • 데이터: 우편번호, 주소1, 주소2 Address – Money(돈): -zipcode : String • 데이터: 금액, 화폐 단위 -address1 : String -address2 : String • 로직: 더하기, 곱하기 등 19
- 20. 도메인 모델의 기본 구성 요소, Aggregate • Aggregate – 관련된 객체들의 묶음 • Aggregate의 특징 – 데이터 변경시 한 단위로 처리 됨 • 비슷한 또는 거의 유사한 라이프사이클을 갖는 객체들 – 특히, 삭제 시 함께 삭제됨 – Aggregate는 경계를 가짐 • 기본적으로, 한 Aggregate에 속한 객체는 다른 Aggregate에 속하지 않음 • Aggregate 필요성 – 많은 도메인 모델을 가능한 간단하고 이해가능한 수 준으로 만들 필요 – 연관의 개수를 줄임으로써 복잡도 감소 20
- 21. Aggregate의 흔한 예, 주문-고객-상품 order item <<Entity>> OrderLine <<Entity>> <<Value>> <<Aggregate Root>> -product : Product <<Aggregate Root>> Option Order -quantity : int Product -id : Integer -id : Integer -lines : List<OrderLine> <<Value>> -name : String -shippingAddress : Address Price -listPrice : Price -value : int <<Value>> customer ItemDetail -description : String <<Entity>> Customer -id : String -name : String -address : Address 21
- 22. 도메인 모델의 기본 구성 요소, Aggregate 루트 • Aggregate는 루트를 가짐 • Aggregate 루트 역할 – Aggregate의 내부 객체들을 관리 – Aggregate 외부에서 접근할 수 있는 유일한 객체 • Aggregate의 내부 Entity/Value는 루트를 통해 접근 – Aggregate에 대한 알맞은 기능을 수행 • 예, 주문 관련 Aggregate 루트인 Order의 기능 – 주문 취소, 배송지 주소 변경, 주문 상품 변경 • 내부 객체들의 연관을 탐색해서 기능 구현 22
- 23. Entity, Value, Aggregate 도출 예, 도메인 분석 • 도메인: 평가 – 직원의 평가 – 평가는 성과 평가와 역량 평가로 구성 – 성과와 역량에 대해 • 본인 평가, 1차 평가, 2차 평가 존재 – 성과 평가 시, • 성과 항목 목록을 입력하고 각 항목에 대한 평가 내용을 입력 – 역량 평가 시, • 미리 정의된 역량 항목에 대한 평가 내용을 입력 23
- 24. Entity, Value, Aggregate 도출 예, 도메인 분석 - 실제표 성과 목적 결과 가중치 본인 평가 1차 평가 2차 평가 평가 전산 고도화 위키 도입 30 의견 / A 의견 / A 의견 / B 그룹웨어 구축 보안 강화 DB 보안 강화 60 의견 / B 의견 / B 의견 / B 보안 프로세스 도입 팀역량강화 팀 세미나 5회 10 의견 / B 의견 / B 의견 / A 영어 참여율 80% 역량 역량 항목 본인 평가 1차 평가 2차 평가 평가 성취 목표 지향 의견 / A 의견 / A 의견 / B 협동 의견 / A 의견 / A 의견 / B 학습 능력 의견 / B 의견 / B 의견 / B 고객 지향 의견 / A 의견 / S 의견 / A 24
- 25. Entity, Value, Aggregate 도출 예 평가 Aggregate self <<Value>> <<Entity>> PerfEvalSet RaterPerfEval first -self : RaterPerfEval -ratee : Employee -first : RaterPerfEval -rater : Employee -second : RaterPerfEval self -itemEvals : List<PerfItemRaterEval> 1 -done : boolean <<Entity>> 1 <<Aggregate Root>> <<Entity>> PersonnelEval <<Aggregate Root>> <<Value>> -id : Integer Employee PerfItem -employee : Employee 1 PerfItemRaterEval -name : String -goal : String -perfEvalSet : PerfEvalSet 1..* -grade : Grade -result : String -perfItems : List<PerfItem> -comment : String -perfItem : PerfItem +evaluatePerfBySelf() +evaluatePerfByFirst() +evaluatePerfBySecond() 1 self <<Value>> RaterCompeEval 1 CompefEvalSet -ratee : Employee first -self : RaterCompeEval -rater : Employee -first : RaterCompeEval -itemEvals : List<CompeItemRaterEval> -second : RaterCompeEval second -done : boolean CompeItemRaterEval -grade : Grade -comment : String 25
- 26. Entity, Value, Aggregate 도출 예, 도메인 분석 - 실제표 perfEvalSet: PerfEvalSet self:PerfEv alSet 성 목적 결과 가중치 본인평가 1차 평가 2차 평가 과 ----- ----- 30 의견 / A 의견 / A 의견 / B self PerfItem <<Value>> <<Entity>> PerfEvalSet RaterPerfEval PerfItem first ----- ----- 60 의견 / B 의견 / B 의견 / B -self : RaterPerfEval -ratee : Employee RaterEval -first : RaterPerfEval -rater : Employee -second : RaterPerfEval self -itemEvals : List<PerfItemRaterEval> ----- ----- 10 의견 / B 의견 / B 의견 / A 1 -done : boolean <<Entity>> 1 <<Aggregate Root>> 역 역량 항목 본인평가 1차 평가 PersonnelEval 평가 2차 량 -id : Integer <<Value>> PerfItem ----- 의견 / A 의견 / A : Employee / B -employee 의견 1 -goal : String PerfItemRaterEval -perfEvalSet : PerfEvalSet -grade : Grade CompeItem 의견 / A : List<PerfItem> B 1..* ----- 의견 / A 의견 / -result : String -perfItems -comment : String RaterEval +evaluatePerfBySelf() -perfItem : PerfItem ----- 의견 / B 의견 / B +evaluatePerfByFirst() / B 의견 +evaluatePerfBySecond() 1 ----- 의견 / A 의견 / S 의견 / A <<Value>> self RaterCompeEval 1 CompefEvalSet -ratee : Employee first -self : RaterCompeEval -rater : Employee self:CompeEv -first : RaterCompeEval -itemEvals : List<CompeItemRaterEval> alSet -second : RaterCompeEval -done : boolean compeEvalSet:CompeEvalSet second PersonnelEval CompeItemRaterEval -grade : Grade -comment : String 26
- 27. 도메인 기능 구현 예 - 본인 성과 평가 기능 • 본인 평가하기 기능 → 평가 Aggregate의 기능 – 본인 평가하기를 구현하려면 • PersonnelEval의 perfEvalSet 필드로 연결된 • PerfEvalSet의 self 필드로 연결된 • RaterPerfEval을 설정 – 피평가자(ratee), 평가자(rater), 각 항목 평가(itemEvals) self <<Entity>> <<Value>> <<Entity>> <<Aggregate Root>> PerfEvalSet RaterPerfEval 1 first PersonnelEval -self : RaterPerfEval -ratee : Employee -id : Integer 1 -first : RaterPerfEval -rater : Employee -employee : Employee -second : RaterPerfEval self -itemEvals : List<PerfItemRaterEval> -perfEvalSet : PerfEvalSet -done : boolean -perfItems : List<PerfItem> +evaluatePerfBySelf() +evaluatePerfByFirst() 1 PerfItem <<Value>> +evaluatePerfBySecond() 1..* -goal : String PerfItemRaterEval -result : String -grade : Grade -comment : String -perfItem : PerfItem 27
- 28. 도메인 기능 구현 예 - 본인 성과 평가 기능 public class PersonnelEval { private PerfEvalSet perfEvalSet; public void evaluatePerfBySelf(List<PerfItemRaterEval> evals, boolean done) { perfEvalSet.setSelf(employee, evals, done); } … } Aggregate Root가 Aggregate의 다른 객체에 위임 public class PerfEvalSet { private RaterPerfEval self; public void setSelf(Employee ratee, List<PerfItemRaterEval> evals, boolean done) { if (self == null) { self = new RaterPerfEval(rater, ratee); } self.change(evals, done); } … } 28
- 29. 도메인 기능 구현 예 - 본인 성과 평가 기능 public class RaterPerfEval { private Employee ratee; private Employee rater; private List<PerfItemRaterEval> evals; private boolean done; public RaterPerfEval(Employee ratee, Employee rater) { this.ratee = ratee; this.rater = rater; } public void change(List<PerfItemRaterEval> evals, boolean done) { this.evals.clear(); PerfItemRaterEval은 Value이고 Immutable 임: this.evals.addAll(evals); 데이터 값 변경이 아닌, 기존 데이터 삭제 후 새로 추가 this.done = done; } … } 29
- 30. 도메인 기능 구현 예 - 본인 성과 평가 완료 여부 • 본인 평가 완료 여부 → 평가 Aggregate의 기능 – 본인 평가 완료 여부를 구현하려면 • PersonnelEval의 perfEvalSet 필드로 연결된 • PerfEvalSet의 self 필드로 연결된 • RaterPerfEval에게 문의 self <<Entity>> <<Value>> <<Entity>> <<Aggregate Root>> PerfEvalSet RaterPerfEval 1 first PersonnelEval -self : RaterPerfEval -ratee : Employee public class PersonnelEval { -id : Integer 1 -first : RaterPerfEval -rater : Employee -employee : Employee -second : RaterPerfEval -itemEvals : List<PerfItemRaterEval> private PerfEvalSet perfEvalSet; self -perfEvalSet : PerfEvalSet -done : boolean -perfItems : List<PerfItem> public boolean isSelfPerfEvaluationDone() { +evaluatePerfBySelf() return perfEvalSet.isSelfDone(); PerfItem +evaluatePerfByFirst() } 1 <<Value>> +evaluatePerfBySecond() -goal : String } 1..* PerfItemRaterEval -result : String -grade : Grade -comment : String -perfItem : PerfItempublic class PerfEvalSet { public isSelfDone() { return self == null ? false : self.isDone(); } } 30
- 31. 도메인 모델의 기본 구성 요소, Repository • Entity를 보관하는 장소 • 기본 규칙: – Aggregate 당 한 개의 Repository 인터페이스 – Aggregate의 CRUD 기본 단위는 루트! • 예외, 성능 상 이유로 Aggregate에 속한 다른 엔티티에 직접 접근할 필요가 있는 경우 별도 DAO 구현 – 예, 리포트 집계 등 • Repository의 기본 인터페이스 – save(루트): 한 Aggregate의 저장 – List<루트> findByName(): 특정 조건으로 검색 – delete(루트): 한 Aggregate의 삭제 31
- 32. Specification을 통한 검색 • Specification – Repository에서 Entity를 검색하기 위한 필터 • DDD에서의 Specification 구현의 모습 public interface Specification<T> { public boolean satisfy(T entity); } public class SomeCustomerRepository implements CustomerRepository { public List<Customer> findBySpecification(Specification<Customer> spec) { List<Customer> all = findAll(); List<Customer> result = new ArrayList<Customer>(); for (Customer c : all) { if (spec.satisfy(c)) { 개념적으로는 맞지만, result.add(c); 모든 Entity 로딩 시, } 성능 문제 발생 } return result; } } 32
- 33. Specification의 조합 • Specification은 서로 조합이 될 때 유용함 – 다수의 Specification을 and/or로 연결 도메인에 맞는 검색 조건 표현 Specification<Customer> ageGtSpec = new AgeGraterThanSpec(20); Specification<Customer> locationSpec = new LocationEqSpec(Location.SEOUL); Specification<Customer> ageLocSpec = Specs.and(ageGtSpec, locationSpec); 검색 조건 조합 List<Customer> custmoers = customerRepository.findBy(ageLocSpec); Composite Pattern (또는 트리 구조) 이용하여 구현 33
- 34. 도메인 모델의 기본 구성 요소, 도메인 레이어의 Service • 한 Entity나 Aggregate에 속하지 않은 도메인 기 능을 도메인 서비스로 분리 – 예, 계좌 이체 • 계좌 이체는 한 계좌 엔티티 객체가 수행할 수 없는 도메인 기능 • 도메인 서비스의 구현 – 다른 도메인 구성 요소 이용해서 기능 구현 • 타 레이어의 서비스와 구분 34
- 35. DDD 쌩기초의 접근법 • 도메인 모델 중심 접근 필요 • 객체 연관 중심 접근 필요 – 도메인 기능 구현 시, 도메인 객체 간 연관으로 풀기 • SQL을 머리에서 버릴 것 (특히, JOIN!) 35
- 36. DDD와 ORM 36
- 37. 메모리는 영원하지 않음 • 안정적인 데이터 관리 위해 객체를 물리적인 기 록 장치에 보관할 필요 • 객체 모델과 일치하는 물리적 데이터 저장소는 흔치 않음 – OODB는 시장에서 실패 – RDBS는 딱 들어맞지 않음 – 기타 NoSQL 역시 정확하게 OO와 일치하진 않음 37
- 38. 차이의 예: 객체 모델과 ER의 대표적인 차이 객체 모델 관계 모델 연관 방향성 양방향 단방향 레퍼런스(필드) 이용 Foreign Key 이용 콜렉션 연관 List, Set, Map 등 콜렉션 사용 Foreign Key 사용 Join/Collection 테이블 사용 다형성 인터페이스/상속 사용 없음 38
- 39. ORM의 필요성 • DDD를 즐겁게 하려면 – 객체를 이용한 모델링 뿐만 아니라, – 객체 모델과 데이터 모델 간 좋은 매핑 도구 필요 • 추천 프레임워크 – JPA (자바의 ORM 표준 스펙) • 객체와 RDB 사이의 모든 매핑을 거의 소화 – 또한, Spring Data 추천 – DB 연동 코드 작성을 위한 노가다 감소 – Spring Data MongoDB 등을 통한 NoSQL과의 매핑 처리 39
- 40. DDD 구현 이야기 40
- 41. 전체 레이어 별 구성 요소 데이터 조회 목적 Repository 접근해서 도메인 객체 구함 도메인 모델을 DTO로 변환해서 제공 데이터 읽기 위한 트랜잭션 범위 지정 도메인 기능 실행 요청 트랜잭션 범위 지정 도메인 모델 객체 제공 영속성 구현 제공 41
- 42. 전체 레이어 별 구현: Spring + JPA Spring Bean Spring MVC Spring Bean Spring TX Spring Bean Spring TX JPA Spring Data JPA Spring Bean JPA 42
- 43. 도메인 레이어 구현 43
- 44. ORM을 이용한 DB와의 매핑: Entity & Value • Entity 당 한 개의 테이블 매핑 • Entity 간 참조 – 대부분 단방향의 Foreign Key로 처리 – 경우에 따라 Join 테이블 이용 구현 • Entity 간 참조는 최대한 단방향으로 – 꼭 필요한 경우에만 양방향 • Value – 엔티티와 한 테이블에 함께 존재 • Value 콜렉션의 경우 Collection 테이블로 Value 구현 44
- 45. Entity & Value 테이블 매핑 예 • 엔티티 간 연관: Foreign Key @Entity @Entity @Table(name = "EMPLOYEE") @Table(name = "ORGANIZATION") public class Employee { public class Organization { @Id @Column(name = "EMPLOYEE_ID") @Id private String id; @Column(name = "ORGANIZATION_ID") private Integer id; @Column(name = "NAME") ... private String name; } @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "ORGANIZATION_ID") private Organization organization; ... } 45
- 46. Entity & Value 테이블 매핑 예 • Entity와 같은 테이블 사용하는 Value @Entity @Embeddable @Table(name = "EMPLOYEE") public class Address { public class Employee { @Column(name = "ADDR_1") @Id private String address1; @Column(name = "EMPLOYEE_ID") private String id; @Column(name = "ADDR_2") private String address2; @Column(name = "NAME") } private String name; @Embedded private Address address; EMPLOYEE ... } EMPLOYEE_ID NAME ORGANIZATION_ID ADDR1 ADDR2 46
- 47. Entity & Value 테이블 매핑 예 • Value의 List 콜렉션: 콜렉션 테이블 사용 @Entity @Embeddable @Table(name = "RATER_PERF_EVAL") public class PerformanceItemRaterEval { public class RaterPerformanceEval { @Column(name = "GRADE_VALUE") private String gradeValue; @Id @Column(name = "RATER_PERF_EVAL_ID") @Column(name = "COMMENT") private Integer id; private String comment; … @ElementCollection } @CollectionTable(name = "RATER_PERF_ITEM_EVAL", joinColumns = @JoinColumn( name = "RATER_PERF_EVAL_ID")) @OrderColumn(name = "LIST_INDEX") private List<PerformanceItemRaterEval> itemEvals; 47
- 48. Repository의 구현 • 인터페이스로 Repository 정의 – 각 ORM 구현체에 알맞게 구현 • 구현 클래스는 Infrastructure 레이어에 위치 public interface PersonnelEvalRepository { public PersonnelEval findByEmployee(Employee emp); PersonnelEval save(PersonnelEval eval); } public class JpaPersonnelEvalRepository implements PersonnelEvalRepository { @PersistenceContext private EntityManager em; public PersonnelEval findByEmployee(Employee emp) { TypedQuery<PersonnelEval> query = em.createQuery( "select p from PersonnelEval p " + "where p.employee = :emp", PersonnelEval.class); query.setParameter("emp", emp); return query.getSingleResult(); } public PersonnelEval save(PersonnelEval eval) { em.persist(eval); } } 48
- 49. Specification의 실제 구현 • Specification으로부터 조건 생성 기능 필요 – CriteriaQuery 생성 or JP QL의 where 절 생성 public class JpaEmployeeRepository implements EmployeeRepository { @PersistenceContext private EntityManager em; public List<Employee> findBySpecification(Specification spec) { TypedQuery<Employee> query = em.createQuery( "select e from Employee e " + "where " + Specs.toJPQL(spec), Employee.class); spec.setParameters(query); return query.getResultList(); } } – Specification을 직접 구현하는 데는 노력 필요 49
- 50. Spring Data JPA Repository 자동 생성 Spring Data JPA Spcification 지원 50
- 51. Spring Data JPA 이용 Repository 구현 • Repository를 위한 메서드 Convention 정의 – 인터페이스로부터 런타임 시, 구현 객체 자동 생성 public interface EmployeeRepository extends Repository<Employee, String> { Employee findById(String userId); Employee findByName(String name); @Query("select e from Employee e left join e.organization o "+ "where e.rateeTypeValue <> 'NOT_RATEE' order by o.name asc, e.name asc") List<Employee> findAllRatees(); } 51
- 52. Spring Data JPA 이용 Repository 구현, Spec 지원 • Specification을 위한 기능 제공 – 검색 조건 표현 위한 Specification 인터페이스 제공 public class EmployeeSpecs { public static Specification<Employee> rateeType(final RateeType e) { return new Specification<Employee>() { @Override public Predicate toPredicate(Root<Employee> root, CriteriaQuery<?> query, CriteriaBuilder cb) { return cb.equal(root.get(Employee_.rateeTypeValue), e.name()); } }; } 조건을 도메인 용어로 표현 public static Specification<Employee> nameLike(final String name) { return new Specification<Employee>() { @Override public Predicate toPredicate(Root<Employee> root, CriteriaQuery<?> query, CriteriaBuilder cb) { return cb.like(root.get(Employee_.name), "%" + name + "%"); } }; } } 52
- 53. Spring Data JPA 이용 Repository 구현, Spec 지원 • Specification을 위한 기능 제공 – Repository 메서드에 Specificiation 지정 가능 public interface EmployeeRepository extends Repository<Employee, String> { List<Employee> findAll(Specification<Employee> spec); } public interface EmployeeRepository extends Repository<Employee, String>, JpaSpecificationExecutor<Employee> { // JpaSpecificationExecutor에 기본 메서드 정의 } 53
- 54. Spring Data JPA 이용 Repository 구현, Spec 지원 • Specification과 Repository의 사용 예 – Repository 메서드에 Specificiation 지정 가능 Criteria와 같은 유연함을 제공 영속 레이어에 대한 의존 제거 (QueryDSL은 EntityManager를 필요) Specifications<Employee> spec = Specifications.where( EmployeeSpecs.rateeType(RateeType.NOT_RATEE)).and( EmployeeSpecs.nameLike("김")); List<Employee> findAll = employeeRepository.findAll(spec); 54
- 55. Lazy & Eager Loading • Entity 간 연관에서 쓰임 고려한 설정 필요 Employee를 가져올 때, 연관된 Organization도 함께 로딩? Eager Loading Employee emp = employeeRepository.findById("madvirus"); Organization org = emp.getOrganization(); org.getName(); 이 때, Organization과 매핑된 테이블에서 데이터 로딩? Lazy Loading 55
- 56. 애플리케이션 레이어/UI 레이어 구현 56
- 57. 전체 레이어 별 구성 요소 데이터 조회 목적 Repository 접근해서 도메인 객체 구함 도메인 모델을 DTO로 변환해서 제공 데이터 읽기 위한 트랜잭션 범위 지정 도메인 기능 실행 요청 트랜잭션 범위 지정 57
- 58. 애플리케이션 레이어 구현 • 애플리케이션 서비스의 정의 – 사용자에게 기능 제공 위한 인터페이스 정의 • 기능명/기능정의 메서드/입력 파라미터/리턴 결과로 구성 • 도메인을 이용한 구현 – Repository에서 Entity를 가져와 – Entity에 기능을 요청 또는 Entity로부터 정보 조회 • 트랜잭션 범위 지정 – 트랜잭션 시작/커밋/롤백 제어 58
- 59. 애플리케이션 레이어 구현 - 서비스 정의 예 public interface ReturnEvaluationService { public ReturnResult returnSelfPerfEval(String rateeId, String raterId); } 처리 결과를 표현 기능 실행에 필요한 입력 public interface SelfPerformanceEvaluationService { SelfPerEvalResult evaluate(SelfPerEvalRequest request); } 59
- 60. 애플리케이션 레이어 구현 - 서비스 구현 예 public class DomainReturnEvaluationService implements ReturnEvaluationService { private PersonnelEvalRepository personnelEvalRepository; @Transactional 스프링 트랜잭션 기능 사용 @Override public ReturnResult returnSelfPerfEval(String rateeId, String raterId) { PersonnelEval personnelEval = checkValidRaterAndGet(rateeId, raterId); personnelEval.returnSelfPerfEval(); return new ReturnResult(rateeId, personnelEval.getEmployee().getName()); } 도메인 객체 사용 private PersonnelEval checkValidRaterAndGet(String rateeId, String raterId) { PersonnelEval personnelEval = personnelEvalRepository .findByEmployeeId(rateeId); if (!personnelEval.getEmployee().checkFirstRater(raterId)) { throw new RuntimeException("1차 평가자만 반려 가능"); } return personnelEval; } … } 60
- 61. UI 레이어의 구현 • UI 레이어의 역할 두 가지 – 사용자의 기능 실행 요청을 애플리케이션 레이어에 전달하기 • 서비스가 요구하는 데이터를 전달하면 끝 • 서비스의 처리 결과를 뷰에 보여주면 끝 – 사용자에게 데이터 보여주기 • 도메인 데이터를 어떻게 뷰에 전달할 것인가? 61
- 62. UI 레이어 구현, 역할 1 - 서비스에 요청 전달하기 • 컨트롤러에서 서비스에 실행 위임 – 서비스의 입력 값 처리 • 커맨드 객체로 받기 (입력 Form으로부터 요청 객체 생성) • 컨트롤러에서 직접 생성 @RequestMapping(method = RequestMethod.POST) public String submit(ModelMap modelMap, SelfPerEvalRequest request) { SelfPerEvalResult result = evaluationService.evaluate(request); modelMap.addAttribute("result", result); 커맨드 객체로 사용 return "eval/self/selfPerfResult"; } @RequestMapping("/review/returnSelfPerfEval") public String returnPerfEval(@RequestParam("rateeId") String rateeId, ModelMap modelMap) { ReturnResult result = returnEvaluationService.returnSelfPerfEval(rateeId, SecurityUtil.getId()); modelMap.addAttribute("result", result); return "review/returnPerfResult"; 컨트롤러에서 직접 생성 } 62
- 63. UI 레이어 구현, 역할 2 - 데이터 보여주기 • UI 레이어에 데이터를 가져오는 기능 구현 – 읽어올 데이터가 많다면, • 컨트롤러와 분리된 별도 객체로 구현 63
- 64. DataLoadingService의 구현 • 도메인 레이어를 이용한 구현 – Repository로부터 필요한 엔티티 구함 • 검색 조건 조합 필요시 Specification을 이용 – 엔티티로부터 UI에 필요한 데이터 추출 • 방법 1, 엔티티를 그대로 리턴하기 • 방법 2, DTO를 이용해서 데이터 전달 • 방법에 따라 트랜잭션 경계가 달라짐 public class DomainEmployeeDataLoader implements EmployeeDataLoader { @Transactional public SomeReturn load(String empId) { Employee emp = employeeRepository.findById(empId); checkNull(emp); return new SomeReturn(emp); } … } 64
- 65. 데이터 보여줄 때, 도메인 객체의 노출 문제! • 도메인 객체를 그대로 UI 레이어에 노출 시 문제 – 도메인 기능이 노출 → 안정성의 문제 • UI 레이어에서 도메인 객체가 제공하는 기능을 실행하면…. – 레이어를 두는 이유가 사라짐!! – 연관된 객체 접근 시 • JPA의 영속성 컨텍스트 범위가 UI 레이어로 확장되어야 함 • 또는 DataLoader에서 미리 읽어야 함 (연관이 Lazy인 경우) <%-- 도메인 객체 노출 시, 문제 가능성 --%> organization이 Lazy면 트랜잭션 범위 확장 필요 <%= employee.getOrganization().getName() %> <% employee.changePassword("", "newPassword"); %> OSIV, No! 65
- 66. 개인적 의견: DTO 내지 상위의 읽기 전용 인터페이스 사용 • UI에서 필요로 하는 데이터만 담고 있는 DTO – DataLoader에서 도메인 객체를 DTO로 변환처리 // DataLoader PersonnelEval eval = personnelEvalRepository.findById(id); ViewDataDTO dto = convert(eval); // DTO: 기본 데이터 타입 사용, getter만 제공 return dto; • Getter만 갖는 상위 Interface – 리플렉션 통해서 메서드 실행이 가능하므로 비추 // DataLoader public PersonnelEvalIF load() { // PersonnelEvalIF는 read only 메서드만 제공 PersonnelEval eval = personnelEvalRepository.findById(id); return eval; } 66
- 67. DTO를 만드는 방법 • 1, 도메인 객체에 getter를 만들어서 값 읽어오기 – 구현 쉬움 – 프로퍼티에 대한 getter 메서드 생성 필요 – getter 메서드가 증가 • 2, 도메인 객체로부터 값을 받을 수 있는 Builder 를 만들어서 DTO 객체 생성하기 – 구현은 다소 복잡 – 단일 Builder 인터페이스를 이용한 DTO 생성 가능 – getter 메서드의 최소화 67
- 68. 정리 68
- 69. Action! • 도메인 모델 개발 – 객체 간 연관으로 사고하는 연습 – ORM(JPA) 이용 매핑 처리 • 레이어 간 명확한 역할 구분 – 모든 도메인 로직은 도메인 레이어에 모이도록 • 도메인 로직이 전 레이어에 퍼지지 않도록! • 리포지토리 구현 – Spring Data 이용하면 좀 더 편리 – Spring Data의 Specification 활용 69
- 70. Q&A 70