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
- SBT
- hibernate
- 엘라스틱서치
- Domain Driven Design
- Storm
- intellij
- spark
- Spring Batch
- Java
- Spring
- Gradle
- Linux
- Spring Boot
- Angular2
- elastic search
- elasticsearch
- Clean Code
- hadoop
- Hbase
- DDD
- 제주
- docker
- hdfs
- nginx
- 도메인주도설계
- Spring XD
- apache storm
- design pattern
Archives
- Today
- Total
욱'S 노트
DDD - 모델 주도 설계 본문
어떤 방법론에서는 분석 모델(analysis model)을 지지하였다. 분석모델에서는 분석과 설계가 섞이면 혼란만 초래한다고 주장하였다. 그러나 이러한 모델의 단점은 초기의 지식 탐구가 코딩이 시작되기 시기 대부분의 지식탐구가 사라진다는 것이다.
모델주도설계에서는 분석과 설계 모델을 나누지 않는다. 이 경우 유의할 점은 기술적 고려사항이 분석에 심각하게 침해되어서는 안된다. 또한 모델이 구현에 너무 비현실적이라면 새로운 모델을 찾아야 한다. 모델링과 설계가 점진적이고 반복적으로 이루어져야 한다.
모델링 패러다임과 도구 지원
모델과 설계가 밀접한 대응을 가능하게하려면 모델의 개념에 직접적으로 대응되는 것을 만들어낼수 있는 소프트웨어 도구가 필요하다. 객체지향 프로그래밍이 가장 효과적인 도구이다. 이는 절차적 언어에 대응하는 모델링 패러다임이 없기 때문이다.
도메인 주도 설계는 모델을 동작하게 만들어 문제를 해결하는 것이다. 모델링을 하는데 있어 역할을 지나치게 구분하지 말자는 것이다. 업무 분석가도 실제 구현 코드를 살필수 있어야 하며 개발자도 모델의 정제에 적극적으로 참여해야 한다.
'Methdology > Domain Driven Design' 카테고리의 다른 글
DDD - 엔티티, VO, 서비스 (0) | 2016.01.27 |
---|---|
DDD - 도메인의 격리 (0) | 2016.01.27 |
DDD - 의사소통과 언어 사용 (0) | 2016.01.27 |
DDD - 지식 탐구 (0) | 2016.01.27 |
DDD - 도메인 모델이란? (0) | 2016.01.27 |
Comments