티스토리 뷰

 

지금까지 개발을 하면서 xxx 주도 설계를 정의하고 시작해본 적은 없지만, 도메인 주도 설계에 대해서는 알고 있었다.

 

MSA에 가장 적합한 설계라는 것 정도로 알고 있었는데, 이 책을 읽고 생각이 조금 바뀌었다. 

 

결국 설계는 서비스가 성장함에 따라서 발생할 수 있는 문제를 해결하기 위한 방법론 중 하나일 뿐이었다.

 

그리고 이 책은 커져가는 서비스에서 발생하는 문제를 도메인 주도 설계라는 방법론을 통해 해결하는 방법을 알려 준다.

 

가장 기억에 남는 말은, 책 서두와 말미에 다음과 같은 문구가 써있다.

 

우리가 해결하고자 하는 문제가 무엇인지 합의하기 전에 해결책을 얘기하는 것은 의미가 없다. 또한 해결책에 대해 합의하기 전에 어떻게 구현하는지 얘기하는 것도 의미 없다.
- 에프랏 골드렛-아쉬라그(Efrat Goldratt-Ashlag)

 

100% 맞는 말이라고는 생각하진 않지만 규모가 있는 개발에서는 모든 팀이 한 곳을 바라보게 끔 만드는 건 매우 중요하다.

 

팀마다 목표가 다르면, 업무의 범위와 책임을 나누는 것부터 문제가 발생하기 때문이다. 

 

그렇게 되면 프로젝트는 보통 늘어지거나 산으로 간다.

 

이런 문제를 해결하기 위한 지표로 북극성 지표가 있다.

 

출처: https://www.waveon.io/blog/north-star-metric

 

북극성 지표는 하나의 목표를 보고 다같이 달려나가는, 목표에 가까워 질수록 성공에 가까워지는 지표다.

 

위와 같이 성공을 위한 지표, 즉 문제를 잘 정의한 곳에서 성공적인 제품이 나온다.

 

북극성 지표와 같이 문제를 잘 정의하고, 문제를 해결하기 위한 방법으로 이 책은 도메인 주도 설계를 제안했다.

 

이 책에서 말하는 도메인 주도 설계로 얻을 수 있는 것들은 다음과 같다.

 

1. 문제를 잘 정의할 수 있다 - 하위 도메인과 유비쿼터스 언어

2. 문제의 범위를 잘 설정하고 경계를 나누는 법 - 바운디드 컨텍스트

3. 정의한 문제를 개발로 풀어내기 위한 과정 - 밸류 오브젝트, 액티브레코드, 애그리게이트

4. 문제를 해결하기 위한 방법들 - CQRS, 이벤트 주도 개발

5. 도메인 주도 설계를 위한 방법론들 

 

다만, 책에서 일반적인 설계에서는 들을 수 없는 생소한 용어가 많이 나와서 어려운 부분이 있다.

 

유비쿼터스 언어부터 핵심 하위 도메인, 바운디드 컨텍스트, 액티브 레코드, 애그리게이트, CQRS 등등...

 

이 중에서 가장 공감되는건 문제를 잘 정의해서 유비쿼터스 언어로 개발팀 뿐만 아니라 다른 사업부서도 동일하게 이야기를 나눠야 한다는 것이었다.

 

그리고 서비스에서는 핵심 하위 도메인이 어려워야 제품으로서 더 좋은 가치가 있다는 것도...

 

개발적인 부분도 새로운 내용을 많이 접했는데, 이벤트 주도 개발과 CQRS에 대한 개념도 잡을 수 있었다.

 

그리고 애그리게이트로 트랜잭션의 범위를 나눈다는 개념도 한번쯤 짚고 넘어가 보는 것도 좋을 것 같다.

 

마치며

개인적으로는 책이 개발만 다루는게 아니고, 비즈니스적인 부분을 다뤄줘서 더 좋았다.

 

하지만 개발자가 아닌 사람들이 보기엔 그닥 좋지 않은 책이다.


그리고 유연한 설계가 시스템의 복잡성을 올려버리는 건 어쩔 수 없다는 걸 다시 한번 느끼게 됐다.

 

실무에서 경험해보지 못한 내용이 너무 많아서 경험이 쌓이면 한번 정도 더 읽어볼 계획이다.

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
글 보관함