Notice
Recent Posts
Recent Comments
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- scala
- elasticsearch
- Angular2
- apache storm
- intellij
- Spring
- Java
- 도메인주도설계
- Spring Batch
- nginx
- spark
- Storm
- Clean Code
- SBT
- Gradle
- Domain Driven Design
- 엘라스틱서치
- design pattern
- hadoop
- DDD
- Hbase
- Spring XD
- hibernate
- elastic search
- hdfs
- docker
- 제주
- 스프링 배치
- Linux
- Spring Boot
Archives
- Today
- Total
욱'S 노트
DDD - 도메인의 격리 본문
Layered Architecture
복잡한 소프트웨어를 만들 경우 관심사의 분리(seperation of concern)가 필요하여 이로써 격리된 상태에 있는 각 설계 요소에 집중 할 수 있다.
사용자 인터페이스 - 일반적인 UI. 간혹 사람이 아닌 컴퓨터 시스템이 외부 행위자가 되기도 함(스케쥴러)
응용 계층 - 얇게 유지되어야 한다. 업무 규칙이나 지식이 포함되지 않으며 도메인간 상호작용만이 존재하며 도메인 객체에 작업을 위임. 작업에 대한 진행상황만을 상태로 가짐
도메인 계층 - 업무 개념 및 업무 상황, 규칙에 관한 정보를 표현 기술적인 세부사항은 인프라스트럭처에 위임
인프라스트럭처 계층 - 상위 계층을 지원하는 일반화된 기술적 기능. - 예) 메시지 전송. 도메인 영속화
안티패턴 - 스마트 UI, 트랜잭션 스크립트
스마트 UI와 트랜잭션 스크립트는 안티패턴으로 본다. 스마트 UI는 말그대로 UI에 많은 기능들이 할애되어 있어 VIEW와 모델의 경계가 모호해진다. 트랜잭션 스크립트도 단순한 어플리케이션을 생성하는데는 적합하나, 서비스에 모든 지식들이 포함되어 적절한 재활용이 어려울뿐더러 변화에 민감하지 못하다. 또한 도메인 모델을 추출해내는데 어려움을 겪을 것이다.
'Methdology > Domain Driven Design' 카테고리의 다른 글
DDD - Aggregate, Factory, Repository (0) | 2016.01.27 |
---|---|
DDD - 엔티티, VO, 서비스 (0) | 2016.01.27 |
DDD - 모델 주도 설계 (0) | 2016.01.27 |
DDD - 의사소통과 언어 사용 (0) | 2016.01.27 |
DDD - 지식 탐구 (0) | 2016.01.27 |
Comments