phantasmicmeans 기술 블로그

기본적으로 우리는 비즈니스 도메인에 깊이 뿌리내린 모델을 만들어야한다. (핵심 개념을 매우 정확하게 반영하는 모델을 만들어야한다.) 그 다음 우리는 이 모델들을 코드로 구현하는 작업을 수행한다. 최고의 모델을 만들었음에도 코드로 적절하게 바꾸지 못하면, 결국 신뢰할 수 없는 소프트웨어가 만들어진다. 어느 도메인이든 다양한 모델로 표현되고, 각 모델들은 다양한 코드로 표현될 수 있다. 또한 특정 문제에 대한 해법도 여러가지 일 수 있다. 우리는 이중 무엇을 택할 것인가? 우리가 품게되는 근본적인 질문은 모델을 코드로 어떻게 변환할 것인가? 하는 것이다. 분석 모델 설계 기법 코드 설계와 분석을 분리하고 분석과 코드 설계를 보통 서로 다른사람이 작업하도록 한다. 분석 모델은 비즈니스 도메인 분석 결과물일 뿐..

유비쿼터스 언어 소프트웨어 전문가와 도메인 전문가가 이야기하다보면 의사소통 장벽으로 인한 근본적 어려움이 있음 도메인 전문가는 DB가 무엇인지 라이브러리가 무엇인지 알지조차 못한다. 자신의 특화된 분야만 알고있다. 외부인들이 이해하기 어려운 자신들만의 전문용어로 이야기한다. 팀 멤버끼리 도메인에 관해 토의할 수 있는 공통언어를 갖지 못하면 심각한 위험에 직면하게 된다. 우리는 모델을 이야기하고 정의할 때 같은 언어로 말할 필요가 있다. 도메인 주도 설계의 핵심 원칙은 모델 기반의 언어를 사용하는 것 > 모델은 소프트웨어와 도메인이 서로 교차하는 지점이기 때문 모델을 언어의 중추로 사용하라 이 언어를 최대한 끊임없이 사용하도록 요구하라 팀이 사용하는 모든 의사소통 형식에 항상 이 언어가 사용되도록 확인하라..

자동화된 비즈니스 프로세스나 현실 세계의 문제가 소프트웨어의 도메인이다. 소프트웨어는 도메인으로부터 시작되고 뗄 수 없는 관계를 가지고 있다. 좋은 소프트웨어를 만들기 위해서는, 그 소프트웨어가 무엇에 관련되어있는지를 알아야한다. 즉 도메인에 대한 깊은 지식이 필요하고, 우리가 출발해야 하는 곳은 언제나 도메인이며 소프트웨어는 도메인을 모델링해야한다. 도메인 전문가와 이야기를 나누며 배운 여러 가공되지 않은 지식들을 기반으로 > 도메인을 추상화해야한다. 즉 추상화 > 도메인을 표현한 모델 모델 모델 == 대상 도메인에 대한 내부적 표현으로 설계와 개발 프로세스 내내 반드시 필요 하나의 도메인에는 모델로 만들기에는 정보가 너무 많기에 대부분은 고려할 필요조차 없다. 은행 소프트웨어는 고객의 주소를 반드시 ..