도메인 주도 설계란 무엇인가?

p.15

소프트웨어는 현실 세계의 프로세스를 자동화하거나 비즈니스 문제를 해결하기 위해 개발된다. 자동화된 비즈니스 프로세스나 현실 세계의 문제가 소프트웨어의 도메인이다. 우선 소프트웨어란 이 도메인으로부터 시작되고 떼려야 뗄 수 없는 관계를 가지고 있음을 반드시 이해해야 한다.

생활의 편리를 위해 만들어지는 서비스, 아이디어, 개선에 관련된 모든 소프트웨어들이 도메인을 기반으로 만들어진다.

 

 

p.16

좋은 소프트웨어를 만들기 위해서는, 그 소프트웨어가 무엇에 관련된 것인지를 알아야 한다. 은행 업무의 모든 것을 알고 그 도메인을 이해하는 사람이 아니면 좋은 은행 소프트웨어를 만들 수 없다. 도메인에 대한 깊은 지식 없이 복잡한 은행 소프트웨어를 만드는 것이 가능할까? 당연히 불가능하다.

내가 만들어 나가고 있는 소프트웨어에서 도메인 전문가는 기획자이다. 기획자분들이 시장 조사를 하고, 벤치마킹을 하고, 아이디어를 짜내며 서비스 기획을 한다. 그러므로 기획자분들이 도메인 전문가다. 그분들과 많은 소통을 통해 도메인 지식을 넓혀 나가야 한다.

 

p.20

지식과 정보가 모두 표현된 모델을 가지고 있을 때 코드 설계를 시작할 수 있다. 코드 설계는 소프트웨어 설계와는 다르다. 소프트웨어 설계는 집의 구조를 만드는 것처럼 큰 그림을 다루는 작업이다. 반면에 코드 설계는 어떤 벽에 그림을 걸지 정하는 것처럼 세부 사항에 관한 작업이다. 코드 설계도 매우 중요한 작업이지만 소프트웨어 설계만큼 기반을 다지는 작업은 아니다.

무조건 소프트웨어 설계가 선행된 후 코드 설계를 진행해야 한다. 소프트웨어 설계를 진행하기 위해서는 도메인에 대한 이해가 선행되어야 한다.

 

p.49

만약 개발자들이 분석가들의 회의에 함께 참여하고, 코드를 설계하기 전에 도메인과 모델을 명확하고도 완전하게 이해한다면 훨씬 더 생산적일 것이다.

 

p.51

객체지향 프로그래밍은 구현과 모델이 같은 패러다임에 기초하고 있기 때문에 모델을 구현하기에 적합하다.

도메인이 객체지향적으로 표현되면 코드를 이해하기 쉽고, 확장성, 유지보수성이 높아진다.

 

p.52

절차적 언어로 작성된 하나의 프로그램은 특정 결과를 얻기 위해 서로를 호출하는 함수들의 집합으로 이해할 수 있다. 이런 프로그램은 개념적 관계를 캡슐화하기 어렵고 도메인을 코드화하기도 어렵다.

 

p.96

리팩터링의 목적은 코드를 나쁘지 않게, 다시 말해 더 낫게 만드는 것이다. 이때, 자동화 테스트를 하면 수정 작업이 기존 기능의 어떤 것도 망치지 않았음을 확신할 수 있다.

꾸준한 리팩터링을 위해서 테스트 코드는 필수이다.

 

p.97

모델링에 대해서 우리가 제일 먼저 배운 것은 비즈니스 명세를 읽고 명사와 동사를 찾는 것이었다. 명사는 클래스로, 동사는 메서드로 변환된다. 이것은 심한 단순화이며 결국 편협한 모델만을 만들어 낼 뿐이다. 모든 모델은 초기에는 깊이가 얕을 수밖에 없으나 모델이 점점 깊은 통찰을 가지도록 개선해야 한다. 설계는 유연해야 한다. 유연하지 못한 설계는 리팩터링을 막는다. 변경이 필요할 때마다 코드와 싸워야 하고, 이 코드를 개선하는 데 많은 시간을 소모할 것이기 때문이다.

복잡한 도메인을 먼저 이해하고, 역할/책임/협력에 기반하여 코드를 설계해야 한다.

 

p.103

제약 사항을 별도의 메서드로 분리하면 이 제약 사항이 명확해진다는 장점이 있다. 이렇게 하면 읽기 쉬울 뿐 아니라 add() 메서드가 이러한 제약 조건의 지배를 받는다는 것을 누구나 알 수 있게 된다. private boolean isSpaceAvailable() ...

코드의 가독성을 위해서 시도해 보자. 제약 조건에 이름을 부여할 수 있어서 코드를 읽을 때 이해하기 쉽겠다.

 

느낀점

이 책을 읽고나니 도메인 주도 설계에 대한 이해도가 이전보다 높아졌다.

도메인 주도 설계는 이전에도 많이 사용했고, 현재도 많이 사용하고 있는 소프트웨어 설계 방법이다.

'도메인 주도 설계' 라는 용어가 새로운 설계 방법론 같이 들리지만 원래 있었던 개념에서 '도메인' 을 더 강조하고 있다고 생각한다.

소프트웨어를 개발하다 보면 마감 기한으로 인해 결과물을 빨리 만들어야 하는 상황들이 비일비재하다.

이러다보니 도메인에 대한 깊이 있는 분석이 부족하다.

깊이가 없는 분석을 통해 소프트웨어 설계가 진행되고 코드 설계가 이뤄진다.

미흡한 도메인 분석으로 인해 소프트웨어를 재설계하고 코드 설계 또한 변경되어질 수 있다.

이런 상황들은 언제든지 발생할 수 있고, 과거에도 현재에도 앞으로의 미래에도 발생될 것이다.

좋은 개발 방법론이 있다 하더라도 사람이 하는 일이기 때문에 문제점들은 언제든지 반복된다.

이런 문제점들을 보완한 것이 애자일 개발 방법론이다.

소프트웨어는 건축과는 다르게 한번 설계한 뒤에도 변경 가능하다.

그래서 개발자들은 코드를 유연하게 작성해야 변경을 쉽고 빠르게 대처 할 수 있다.

코드간의 의존성을 최대한 느슨하게 하고, 응집도를 높이는 코드를 잘 만들어 나간다면 어떠한 변화가 찾아오더라도 쉽게 대처 가능하다고 생각한다.