소프트웨어 설계에 도메인 모델링이 중심이 되고 있습니다. 비즈니스 도메인을 중심으로 소프트웨어 개발자는 사용자의 요구를 충족시키는 풍부한 기능성을 표현하고 구현할 수 있어야 합니다. 도메인 전문가(a.k.a 현업)과 긴밀한 커뮤니케이션과 협력으로 효과적인 어플리케이션을 구축해야 합니다.
도메인 주도 설계 | Domain-Driven Design (DDD)
Manufacturing은 소프트웨어 개발에 널리 사용되는 메타포입니다. 이 메타포에 한 가지 추론할 수 있는 것은 고도로 숙련된 엔지니어는 제품을 설계하고, 덜 숙련된 노동자는 설계된 제품을 조립합니다. 많은 프로젝트는 메타포로 인해 실패하게 되었습니다. 소프트웨어 개발은 모두 디자인입니다. 모든 팀은 전문적인 역할을 가지고 있지만, 분석, 모델링, 설계 및 프로그래밍에 대한 과도한 책임 분리는 모델 주도 설계를 방해합니다.
Eric Evans, Domain-Driven Design
소프트웨어 코드의 구조와 언어(클래스명, 메소드, 변수)가 비즈니스 도메인과 일치해야 한다는 컨셉입니다. 예를 들어, 대출 신청 처리 소프트웨어를 개발한다고 할 때, 클래스에는 'LoanApplication', 'Customer'로 구성 할 수 있고, 메소드에는 'AcceptOffer'와 'Withdraw'로 작성 할 수 있습니다.
도메인 주도 설계의 핵심은 다음과 같습니다.
- 핵심 도메인 및 도메인 로직를 프로젝트의 주요 초점 설정
- 도메인 모델을 기반으로 디자인
- 기술 전문가와 도메인 전문가이 창의적 협력으로 도메인 문제를 해결하는 모델 생성
기술적으로 구현하기 위해서는 느슨한 결합(Loosly Coupling), High Cohesion
- Concept : 의미를 결정하는 단어나 문장이 나타나는 설정
- Domain : 지식의 영역(Ontology), 영향력 또는 활동. 사용자가 프로그램을 적용하는 대상 영역은 소프트웨어의 도메인
- Model : 도메인의 선택된 측면을 설명하고 해당 도메인과 관련된 문제를 해결하는데 사용할 수 있는 추상화 시스템
- Ubiquitous Language : 도메인 모델을 중심으로 구조화 되고 모든 팀 구성원이 팀의 모든 활동을 소프트웨어와 연결하는 데 사용 하는 언어
대부분의 사람들은 '설계를 고민한다는 것'이 '어떻게 생긴 것인지 고민하는 것'으로 착각한다. 설계자에게 어떤 박스를 주며 "좋아 보이게 만들어봐!" 수준으로 생각한다. 이건 우리가 생각하는 설계가 아니다. 설계는 단지 어떻게 생겼는지, 어떤 느낌인지가 아니다. 그게 어떻게 동작하는지에 대한 것이다.
Steve Jobs, Co-founder of Apple
