욱'S 노트

Layered Architecture 복잡한 소프트웨어를 만들 경우 관심사의 분리(seperation of concern)가 필요하여 이로써 격리된 상태에 있는 각 설계 요소에 집중 할 수 있다. 사용자 인터페이스 - 일반적인 UI. 간혹 사람이 아닌 컴퓨터 시스템이 외부 행위자가 되기도 함(스케쥴러)응용 계층 - 얇게 유지되어야 한다. 업무 규칙이나 지식이 포함되지 않으며 도메인간 상호작용만이 존재하며 도메인 객체에 작업을 위임. 작업에 대한 진행상황만을 상태로 가짐도메인 계층 - 업무 개념 및 업무 상황, 규칙에 관한 정보를 표현 기술적인 세부사항은 인프라스트럭처에 위임인프라스트럭처 계층 - 상위 계층을 지원하는 일반화된 기술적 기능. - 예) 메시지 전송. 도메인 영속화 안티패턴 - 스마트 UI, ..

어떤 방법론에서는 분석 모델(analysis model)을 지지하였다. 분석모델에서는 분석과 설계가 섞이면 혼란만 초래한다고 주장하였다. 그러나 이러한 모델의 단점은 초기의 지식 탐구가 코딩이 시작되기 시기 대부분의 지식탐구가 사라진다는 것이다. 모델주도설계에서는 분석과 설계 모델을 나누지 않는다. 이 경우 유의할 점은 기술적 고려사항이 분석에 심각하게 침해되어서는 안된다. 또한 모델이 구현에 너무 비현실적이라면 새로운 모델을 찾아야 한다. 모델링과 설계가 점진적이고 반복적으로 이루어져야 한다. 모델링 패러다임과 도구 지원 모델과 설계가 밀접한 대응을 가능하게하려면 모델의 개념에 직접적으로 대응되는 것을 만들어낼수 있는 소프트웨어 도구가 필요하다. 객체지향 프로그래밍이 가장 효과적인 도구이다. 이는 절차..

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

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

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