일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- @EnableScheduling
- K번째수
- 스프링 스케쥴러
- @Data
- @Getter
- kubenetes
- 모던 자바 인 액션
- 고차원 함수
- 알고리즘
- 커링
- 스택/큐
- Java
- @configuration
- 쿠버네티스
- 완주하지 못한 선수
- 다리를 지나는 트럭
- 코딩 테스트
- 크론 표현식
- H-index
- 정렬
- 롬복 어노테이션
- 루씬 인 액션
- 영속 자료구조
- 검색 기능 확장
- 기능개발
- 프로그래머스
- 전화번호 목록
- 해시
- @Setter
- 가장 큰 수
- Today
- Total
목록도메인 주도 설계 (25)
Today I Learned
소프트웨어 구현을 건전한 상태로 유지하고 모델과 밀접한 관계를 유지하려면 모델링과 설계의 우수 실천법을 적용해야 한다. 도메인 주도 설계 과정을 탄력성 있게 만들려면 근본 원리들이 어떻게 MODEL-DRIVEN DESIGN을 뒷받침하는지 이해해야 한다. 내비게이션 맵은 표준 패턴과 패턴 간의 관계를 보여준다. 표준 패턴을 공유하면 설계에 체계가 생겨 각 구성원의 다른 업무를 쉽게 이해할 수 있다.
소프트웨어를 개발하는데 직접적으로 도움을 주지 않는 도메인 모델은 의미가 없다. 도메인 주도 설계에서는 초기 분석 단계에 도움이 될 뿐 아니라 설계의 기반이 되는 모델이 필요하다. MODEL-DRIVEN DESIGN (모델 주도 설계) 코드와 모델이 긴밀하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다. 설계와 모델이 대응하지 않는다면 모델은 가치가 없어지고 소프트웨어의 정확성은 의심스러워진다. 분석 모델(analysis model) 소프트웨어 시스템에서 수행할 역할에 대해 고려하지 않고 업무 도메인의 개념만을 체계화한 모델 오로지 이해하기 위한 수단으로 간주되며, 구현 관심사와 섞일 경우 혼란만 초래하는 것으로 여겨짐 설계/구현 단계에서 발견된 문제들은 반영되지 못함 분석과 설계 ..
UBIQUITOUS LANGUAGE (보편언어) 도메인 모델은 소프트웨어 프로젝트를 위한 공통 언어의 핵심 모델 기반의 의사소통은 통합 모델링 언어(UML) 상의 다이어그램으로 한정되어서는 안된다. 유연하고 풍부한 지식이 담긴 설계를 만들려면 다용도로 사용할 수 있는 팀의 공유 언어와 그 언어에 대한 활발한 실험이 필요하다. 공통 언어가 없는 프로젝트의 문제점 도메인 전문가는 원하는 바를 모호하게 설명하고, 개발자가 이해하는 바도 모호한 수준에 머문다. 도메인 전문가와 개발자가 서로 자신들의 언어를 번역해줘야 하며, 이또한 정확하지 않다. 의사소통이 직접적으로 일어나지 않기 때문에 개념이 분열돼도 겉으로 드러나지 않는다. 번역은 의사소통을 무디게 하고 지식 탐구를 빈약하게 만든다. 유용한 모델을 만들기위..
초기 모델 설계는 개발자와 도메인 전문가 간의 논의를 통해 발전한다. 개발자는 도메인을 이해하며 모델을 설계하고, 도메인 전문가는 설계된 모델 이해하고 피드백하며 양방향으로 소통한다. 효과적인 모델링의 요소 1. 모델과 구현의 연계 2. 모델을 기반으로 하는 언어 정제 3. 풍부한 지식이 담긴 모델 개발 4. 모델의 정제 5. 브레인스토밍과 실험 지식 탐구 폭포수 개발 방식 업무전문가가 분석가에게 설명 → 분석가가 이해한 내용을 바탕으로 추상화해서 프로그래머에게 요청 프로그래머가 도메인에 관심이 없다면 눈에 보이는 수행만 구현 지식은 한방향으로만 흐르고 축적되지 않는다. 프로그래머가 처음부터 추상화된 모델로 구현할 수도 있다. 하지만 기초적인 역할만 수행 가능하고 도메인 전문가의 사고방식과 긴밀하게 연결..