욱'S 노트

도메인 모델은 공통언어의 핵심이자 도메인에 대한 통찰력을 반영하는 용어와 관계로 표현된다. 모델기반의 의사소통으로 꼭 UML을 사용해야 하는 것은 아니다. 어떠한 의사소통 수단을 사용해도 무방하며 형식에 얽매이지않는 다이어그램이나 텍스트문서도 가능하다. 또한 코드 자체를 통할 수도 있다. UBIQUITOUS LANGUAGE 도메인 전문가와 개발자가 각자 자기의 언어를 사용하면 안된다. 이는 정보 흐름의 병목으로 이어지며 그들이 번역하는 바도 정확하지 않다.유비쿼터스 언어를 사용하지 않을때 발생하는 문제는 다음과 같다. - 각자의 언어로 얘기를 하기 때문에 토론이 되지 않는다. - 용어와 코드의 정보가 단절된다.- 번역은 의사소통을 무디게 하고 지식탐구를 빈약하게 만든다. 브레인스토밍과 실험 중 언어에 공..

효과적인 모델링의 요소 모델과 구현의 연계 - 반복주기 내내 연결고리를 유지해야 한다.모델을 기반으로 하는 언어 정제 - 누구라도 모델의 내용을 별도 해석 없이 이해할 수 있어야 한다.풍부한 지식이 담긴 모델 - 데이터 스키마뿐만 아니라 행위와 규칙까지 모두 표현모델의 정제 - 중요한 개념은 계속해서 더해져야 하며, 쓸모가 없어진 개념은 제거되어야 한다.브레인스토밍과 실험 - 계속해서 토의해야 하며 실험실로 옮겨 테스트를 해야 한다. 지식탐구 폭포수개발 방식 - 업무전문가 -> 분석가 -> 프로그래머, 피드백이 전혀 없어 실패할 수 밖에 없음이터레이션 방식 - 모델을 만들지 않음. 추상화가 되지 않아 지식 축적이 실패. 모델과 구현이 떨어짐 즉 업무전문가, 분석가, 프로그래머가 함께 모델을 만들어야 하며..

도메인이란? 소프트웨어로 해결하고자하는 문제 및 관심사. 일반적인 경우 비즈니스적인 성격을 띄지만, 몇가지 예외적인 예로 인프라스트럭처 자체가 도메인이 될 수도 있다. 소스관리 시스템, 배치스케쥴링 시스템등은 소프트웨어 자체가 도메인일 수 있다. 도메인 모델이란 ? 도메인주도설계에서 모델이란 도메인의 추상화이다. 즉 현실세계에 실재하는 문제에 대한 지식을 선택적으로 단순화하고 문제해결을 위해 구조화한 형태이다. 이는 현실을 사실적으로 반영하지 않고 문제해결을 위해 인위적으로 단순화된다. DDD에서 모델의 중요성 모델과 설계는 서로 영향을 주며 구체화된다. - 모델은 구현까지 긴밀하게 유지되며 유지보수되어야 한다.모델은 모든 팀구성원이 사용하는 유비쿼터스 언어이다. - 모든 구성원들은 모델을 통해서 의견을..

minimum granularity process에 부과된 최소 timeslice

부모-자식 관계는 본질적으로 내포된 모델과 비슷하다. 그러나 차이가 있다면 내포된 오브젝트는 하나의 도큐먼트에 저장되는 반면, 부모-자식에서는 부모와 자식이 완전하게 다른 도큐먼트로 저장된다는 것이다. 부모-자식 기능은 하나의 도큐먼트 타입이 다른 것과 연관되게 해준다. 내포된 오브젝트와 비교한 이점은 다음과 같다. 자식 도큐먼트의 리인덱싱 없이 부모 도큐먼트를 업데이트 할 수 있다.부모와 다른 자식의 영향 없이 자식 도큐먼트를 추가 변경 삭제할 수 있다. 이것은 특히 자식 도큐먼트들이 다수이고 자주 변경되고 추가될때 유용하다.자식 도큐먼트는 검색의 결과로 리턴될 수 있다.엘라스틱서치는 부모와 연관된 자식을 매핑을 유지하고 있어서 쿼리타임에 빠르게 조인할 수 있다. 그러나 이 경우 부모 자식 관계의 한계..