욱'S 노트

도메인 전문가와 이야기를 하다보니 커뮤니케이션에 장벽을 느낄 수 있다. 개발자는 모든 생각이 클래스, 메소드, 알고리즘, 패턴등 프로그래밍 요소들에 가 있을 것이다. 혹은 항상 관계, 상속, 다형성, OOP 등을 생각할 수 도 있다. 하지만 도메인 전문가들은 라이브러리, 프레임워크, 데이터베이스 등에 아무런 관심이 없다. 이러한 상황을 극복하기 위해 모델을 정의할 때. 모델에 대한 반드시 생각이 교환해야 한다. 만약 한 사람이 말한 것을 다른 사람이 이해하지 못한다면 그 프로젝트는 성공할 수 없을 것이다. Domain-Driven Design의 핵심 원칙은 모델을 기초로한 언어를 사용하는 것이다. 모델은 공통영역이므로 소프트웨어와 도메인이 만날 수 있다. 공통언어는 하룻밤 사이에 나타나지 않을 것이다. ..

비행기 운항 제어 시스템을 고려해보자. 이 시스템의 목적은 비행기가 운항중인 경로를 추적하고, 잘 진행되고 있는지 모니터링하는 것이다. 어디서부터 시작해야 되나? 도메인을 이해하는 것부터 시작하자. 항공운항관리사가 도메인을 가장 잘 아는 스페셜리스트이다. 하지만 그는 시스템 설계자도 아니고, 소프트웨어 스페셜리스트도 아니다. 항공운항관리사는 도메인에 대한 넓은 지식을 가지고 있다. 하지만 모델을 구축하기 위해 우리는 핵심 정보를 추출하고 일반화 할 필요가 있다. 전문가와 대화를 하다보면 착륙, 충돌 위등 엄청난 양의 정보가 있다는 것을 알 수 있다. 그러나 어디선가 모델링을 시작해야 한다. 항공운항관리사와 당신은 각 비행기는 출발지와 도착지를 가지고 있다는 것에 동의했다. 간단하게 다음과 같이 그릴 수 ..

소프트웨어에서 도메인이란 소프트웨어에서 실제 해결해야될 문제점을 의미한다. 도메인에 대한 이해없이 복잡한 소프트웨어를 개발하는 것은 불가능하다. 그렇다면 누가 가장 많은 도메인 지식을 가지고 있나? 그것은 소프트웨어 아키텍트도 아니고 비즈니스 컨설턴트도 아니다. 개발자는 더더욱 아니고. 정답은 현업 혹은 사용자이다. 그들은 비즈니스를 가장 잘 이해하고 있는 사람들이다. 소프트웨어 프로젝트를 첨 시작할 때 도메인에 초첨을 맞춰야 한다. 가장 좋은 방법은 도메인을 반영한 소프트웨어를 설계하는 것이다. 소프트웨어는 코어 컨셉과 도메인 요소를 포함해야 하며 둘의 관계를 반영해야 한다. 해당 소프트웨어에 대한 지식이 없는 사람도 도메인 모델의 코드를 읽으면 해당 도메인에 대해 알 수 있어야 한다. 도메인을 추상화..