[DDD Start] 2장 아키텍처 개요
들어가는 글: 2장은 DDD를 설명하기 위한 기본 구성요소 그리고 배경 지식에 대해서 좀더 알려줍니다. 아키텍처에 관하여 간만에 조금더 생각해볼 수 있는 시간이 되었습니다.
아키텍처의 4개 영역
출처: http://www.sei.cmu.edu/architecture/사실 아키텍쳐의 구분은 확실하게 정해진 것은 없으나 DDD Start에서는 일관되게 아래의 4계층을 설명하고 있습니다.
1) 표현(Presentation) .. UI, 사용자와 인터렉션을 담당
>> Presentation, View 다 같은 얘기입니다. 순수하게 사용자 처리 부분만 분리해내는게 목표입니다. 하지만 실전 프로젝트에서는 쉽지가 않는 것도 사실입니다. 저도 안드로이드 앱을 개발하고 있지만 순수하게 View를 발라내기 보다는... 오히려 핵심 로직을 View없이 순수하게 유지하는 것이 더 중요하다는 생각입니다.
2) 응용(Application) :
시스템이 사용자에게 제공해야 할 기능 제공
도메인 영역의 도메인 모델을 호출(위임)
>> 음.. 이 layer가 젤 애매모호합니다. 마치 여집합 같은 느낌이네요. 핵심 로직은 도메인 영역에 담겨 있고, View는 아니지만 도메인도 아닌 나머지가 위치하는 layer같기도 합니다.
3) 도메인(Domain): 도메인 모델을 구현 .. 이책에서 설명하고자 하는 부분
예) Order, OrderLine, ShippingInfo 객체등이 존재함
4) 인프라(Infrastructure): 외부 구현 기술을 다룸
향후에 대체(replace)하거나 제거(remove)할 수 있도록 외부(3rd party) 라이브러리 혹은 구현체, 솔루션을 모아 놓은 layer
예) RDBMS연동, 메시징 큐, SMTP 등
"도메인 영역, 응용 영역, 표현 영역은 구현 기술을 사용한 코드를 직접 만들지 않는다(39p)"
>> 이것이 실전에서 가능하기는 한 것일까? 그러면 왜 3개 계층이나 필요한 것일까? 순수 로직만 넣는다면....
[그림 2.4] 에 따르면
표현 -> 응용 -> 도메인 -> 인프라 ..의 layer적인 참조뿐만 아니라
표현 -> 도메인
응용 -> 인프라 의 참조도 가능하다고 합니다.. 음.. 그렇다면 더더욱 layer의 의미가 모호해지는 것 같네요.
"구현의 편리함을 위해 계층 구조를 유연하게 적용한다(41p)" >> 항상 주의해야 하는 말
"인프라에 의존하게 되면 '테스트 어려움'과 '기능 확장의 어려움'의 문제가 발생한다(44p)"
>> 그리고 인프라의 정의에 따르면 표현 -> 인프라.. 도 가능해야 합니다. View에 특화된 외부 기술이 충분히 존재하니까요. 예) ButterKnife http://jakewharton.github.io/butterknife/
>> 계층 구조의 가장 전형은 OSI 7 layer입니다.
충분히 곱씹어 볼만한 내용을 담고 있습니다. 여기에는 도메인이라는 개념은 없습니다. 응용에 포함되는 개념입니다.
https://ko.wikipedia.org/wiki/OSI_%EB%AA%A8%ED%98%95 (위키백과)
DIP(의존성 역전 원리)
출처: http://vandbt.tistory.com/42"저수준 모듈이 고수준 모듈에 의존하도록 바꾼다 (45p)"
"의존 주입을 지원하는 스프링과 같은 프레임워크를 사용하면 설정 코드를 수정해서 쉽게 구현체를 변경할 수 있다(48p)"
>> 왜 바꿀까? 바꾸는게 더 유리하니까.
>> 무엇이 유리할까?
1) 외부 라이브러리를 교체하기 쉬우니까
2) 외부 라이브러리를 주입하면 되니까
[그림 2.8]
고수준 : CalculateDiscountService - - - > RuleDiscounter (Interface)
저수준 : ◁- - - DroolsRuleDiscounter
잘못된 예
[그림 2.10]
고수준: CalculateDiscountService
저수준 : - - -> RuleEngine(Interface) ◁- - - DroolsRuleDiscounter
>> 인터페이스는 상위 수준에서 정의되어야 한다. 개별 외부 기술에서 제공하는 인터페이스가 아님.
>> 상위 수준의 변경없이 하위 모듈을 교체할 수 있게 됨
>> 하지만 실전에서 3rd party 라이브러리를 바꾸면 상위 인터페이스도 어느정도 바뀌게 마련임.
도메인 영역의 주요 구성요소
엔티티
"엔티티는 단순히 데이터를 담고 있는 데이터 구조체라기보다는 데이터와 함께 기능을 제공하는 객체다. 기능 구현을 캡슐화해서 데이터가 임의로 변경되는 것을 막는다(56p)"
밸류
"RDBMS와 같은 관계형 데이터베이스는 밸류 타입을 제대로 표현하기 힘들다(56p)"
>> 역사적으로 객체 지향 DB는 성공하지 못하였다. (위키백과)
애그리거트
: 엔티티의 그룹, 엔티티는 너무 작은 개념이라 이것만으로는 안된다. 의사소통이 안된다.
>> 개념간의 혼동
도메인 모델 : 엔티티 / 애그리거트
SW 설계: 상위설계 / 상세설계
DB 설계: 논리모델 / 물리모델
==> 어느 설계도 한방에 완벽할 수는 없다.
"트랜젝션에 대한 고려가 필요하다(61p)"
"애그리거트 루트를 통해서 간접적으로 애그리거트의 다른 앤티티나 밸류 객체에 접근하게 된다(60p)"
리포지토리
: 엔티티(에그리거트)를 로딩하고 CRUD 담당 / DB에서 오니까
가장 기본이 되는 메소드
1) 저장 : save(entity) .. CRUD
2) 검색: findById(id) .. 로딩
>> 도메인 서비스는 아직 잘 모르겠음
요청 처리 흐름
모듈 구성
>> 크게 중요한 내용은 아닌 듯
2016.7.27 @Home
