도메인 주도 설계 DDD

DDD ( Domain Driven Design ) [ 도메인 주도 설계 ]

• DDD : 소프트웨어를 이해하고 프로젝트를 성공적으로 완성하기 위한 사고방식
• 도메인 : 사용자가 사용하는 것
  • 도메인은 사용자에 따라 또는 사용자가 바라보는 관점에 따라 지속적으로 변화함

도메인에서 말한 사용자는 누구인가?
사용자라는건 매우 추상적이기에 이 접근을 통해 자기 자신을 포함해서
그 소프트웨어와 관련된 모든 사람이 사용자라고 할수 있다

 

사용자가 사용하는 것 이라 한다면 단 하나의 코드가 될수 있고 하나의 버튼이 될수도 있으며 소프트웨어 전체가 될수도 있다.
예를 들어 요리사가 소프트웨어에서 요리 이미지를 볼 수 있다고 하면 그 요리 이미지는 하나의 도메인이고, 개발자가 조건문 하나를 가지고 고민하고 있다면 그 조건문도 하나의 도메인이 될수 있으며 기획자가 데이터를 소프트웨어에 효율적으로 반영하기 위해 둘러보고 있다면 그 데이터들도 도메인이라 할 수 있다. 도메인은 바라보는 관점에 따라 지속적으로 변화하기에 위에서 말한 모든 것들이 도메인이 될 수 있다.

DDD를 프로젝트에 반영하기 위해서는 소프트웨어 기술보다 도메인이 더 높은 우선순위를 가져야 하고 어떤 문제를 해결하기 위해서는 항상 도메인을 먼저 고민하는 것을 필요로 한다.

프로젝트에서의 고민

DDD의 사고방식을 반영한 실무 프로젝트에서 도메인은 시간이 흐름과 동시에 지속적으로 변경된다. 사용자들이 변경됨과 동시에 그 사용자들이 바라보는 관점도 변화한다. 소프트웨어 프로젝트에서 처음부터 완벽한 요구사항은 없고, 소프트웨어는 지속적으로 변화하며 , 변화하지 않은 소프트웨어는 이미 죽은 소프트웨어와 같다. DDD가 반영된 소프트웨어는 수많은 도메인의 집합체다. 도메인의 변경은 곧 소프트웨어의 직접적인 변경으로 이어진다.

DDD 협업

소프트웨어 구조는 도메인과 도메인 간의 관계가 반영된다.
요구사항 수집 ,우선순위 결정 ,개발 환경 구성 ,설계 ,구현 , 테스트 ,배포 까지의 프로젝트의 전 프로세스에 도메인들이 사용된다. 이때 도메인들의 용어를 보편언어(Ubiquitous language)라 한다. 보편 언어는 모든 사람들이 동일한 의미로 이해하고 있는 단어다. 특정 도메인 A는 모든사람이 프로젝트 관련사람 모두가 A로써 이해하고 있어야 하며 누군가 A-1 로 이해하고 있다면 보편언어를 사용할 수 없으며 이해를 맞추기 위한 추가적인 소통을 필요로 한다. 보편언어의 이해가 맞지 않다면 소프트웨어 곳곳에 어긋남이 있을것이고 여러 문제들과 이해를 맞추기 위해 회의가 계속 이루어져야 한다. 즉, DD를 반영함에 있어서 모든 소통과 프로세스는 도메인(보편 언어)을 일관 되게 맞추고 이해하는 것을 중심으로 만들어진다.

도메인을 사용하는 프로젝트 관점

• 기술적인 관점 ( 개발자 시점 )
  • 구조를 기술적으로 마음대로 변경할 수 없다
  • 도메인을 벗어나서 무언가를 구현할 수 없다
• 도메인 관점 ( PM 시점 )
  • DDD는 개발자의 자유를 제한하지 않는다
  • 오히려 생각할 수 있는 범위가 단순히 기술적인 영역에서 도메인까지 훨씬 더 넓어졌다고 할 수 있다

자유롭게 움직일 수 있는 영역이 달라졌다고 할 수 있다.
개발자가 도메인을 이해하며 도메인 전문가와 함께 만들어 나아가는 것이 DDD의 협업이다.

의존성 관리

DDD 관점에서 보면 도메인을 구성한다는 것은 사용자가 사용하는 영역을 정의하고 설계하는것을 의미한다.
도메인으로 그 영역을 한정하고, 연결 관계(의존성) 을 제어한다.

User Interface 즉 UI 를 디자인하고 개발자나 기획자에게 공유하게 되는것부터
사용자가 사용하는 영역을 한정 시키게 된다.
사용의 범위를 한정시키는 것은 사용자의 자유를 제한한다는 점에서 부정적이게 보일 수 있지만
원하는 것을 할 수 있다는 것을 보장한다
위에서 말했듯이, 의존성 관리는 사용자에게 공유하기 위한 인터페이스를 정의하고 설계하는것을 의미한다

DDD는 사고방식이라 했다.

사용자가 무엇을 필요로 하는지 먼저 생각하고, 사용자가 알 필요가 없는 부분은 사용자에게 공유하지 않음으로써 , 의존성을 관리한다.

모든것은 이 도메인을 중심으로 이루어진다.

도메인은 사용자가 필요로 하는 최소한의 요구사항이자, 최대한의 요구사항이다.

모든 연결은 사용자가 필요로 하는 것들과 관련되어 있다.

Bounded Context

소프트웨어 개발을 하면서 어떤 이슈를 발견하게 되면 그 한계로 인해 side-effect 가 발생하게 되는데 언제 어디서 어떤일지 발생할지 쉽게 알 수 없다. 이것도 도메인을 통해 side-effect 를 관리할수 있다. 도메인은 소프트웨어에서 사용자가 알 수 있는 곳에 있으므로, 무언가 변경이 필요하면 관련된 요소들이 무엇인지 쉽게 찾을 수 있다.

도메인에 집중하면 도메인이 설명하는 범위와 도메인 간의 경계들이 명확하게 드러나는데 이를 Bounded Context 라 한다.

Bounded Context 는 하나의 도메인 또는 도메인의 집합이며 , DDD 에서 소프트웨어를 쉽게 바라볼 수 있도록 하는 시야를 제공한다.

A,X,Y 가 있을 때 , A 와 X가 관련되어 있다면 Bounded Context 를 위와 같이 나타낼수 있다.

도메인 A 가 변경된다면 도메인 X가 영향을 받고 도메인 Y는 관련이 없다는 걸
Bounded Context 로
가독성과 함께 복잡성 (의존성)을 관리 할 수 있다.
주어진 문제를 해결하기 위해 무엇을 해야하는지, 쉽게 접근할 수 있고
불필요한 시간의 소비와 예상치 못한 side-effect 를 최소화 할 수 있다.

해당 글은 아래 사이트 글을 보고 정리한것입니다.

내용은 동일하고 제가 기억할만한 것만 추려서 정리한 것이니
보다 자세히 알고싶으신 분들은 아래 글을 확인해주세요.

도메인 주도 설계(Domain-Driven Design) in Real Project — 도메인