객체지향 잘 설계하는 법

DDD에 대해서 전문적으로 아는건 아니지만 DDD는 단지 객체지향을 잘 짜는 법이라고 생각한다.

잘 설계된 객체지향의 패턴은 무엇인가?

1. 적당히 잘 나눠야한다.
2. 적당히 잘 뭉쳐야한다.
3. 뭉친것끼리 잘 메세지를 주고 받아야한다.
4. 메세지를 주고 받을 때 성능, 보안, 안정성등을 확보해야한다.

소프트웨어를 설계하는 데 적당히란 워딩이 맘에 안 들수 있다. 하지만 저 '적당히'란 말이 설계의 본질이다.

모든 건 트레이드 오프다.

소프트웨어에서 절대적인 솔루션, 단점이 없는 솔루션, 모든걸 해결해주는 솔루션 따윈 없다.

모든 선택은 장단점이 존재하기 때문에 상황을 분석해서 가장 적당한 솔루션을 선택해야 한다.

내가 지어낸 소리가 아니고 아키텍트들이 하는 소리이다.

프로젝트 설계를 할 때 가장 어려운 점이 바로 위와 같은 소프트웨어의 본질 때문이다.

적당히의 기준이 존재하지 않기 때문에 선택은 항상 주관적일 수 밖에 없다.

객체지향을 예를 들면

1. 요구사항에 맞게 적당히 비지니스 로직을 나눈다.
2. 요구사항에 맞게 적당히 비지니스 로직을 뭉친다.
3. 요구사항에 맞게 경계끼리 통신을 한다.
4. 요구사항에 맞게 튼튼한 통신을 구현한다.

DDD는 이런 '적당히'란 기준을 잡는걸 도와주는 길잡이 역할을 한다.

DDD의 주체

그럼 DDD의 대상이 뭘까? 당연히 내가 전 시리즈에서 말했듣이 요구사항이다.

애초에 요구사항을 잘 이끌어내지 못한다면 이런 적당히란 과정을 시작조차 못한다.

따라서 DDD의 시작은 요구사항을 잘 이끌어내는 것부터 시작한다.

DDD의 시작은 용어집이다.

다시 소프트웨어는 돈을 버는 행위란걸 명시한다.
돈을 벌기 위해선 고객이나 사용자를 만족시켜야한다.
고객이나 사용자를 만족시킬려면 그들의 요구사항을 만족시켜야한다.

따라서 DDD는 고객과 소통을 통해서 요구사항을 최대한 구체적으로 잡는것부터 시작한다.

우선 고객과 원할한 소통이 되어야 요구사항을 원만하게 이끌어 낼 수 있다.

그래서 DDD는 유비쿼터스 언어란걸 정의한다.
대충 말해서 개발자가 고객이 자주 사용하는 용어 위주로 정의하는 것.

이과놈들이랑 이야기 할때 필요도 없는데 전문용어, 영어쓰는 사람들 짜증나지?

평소에도 대화하는데 안 그래도 되는데 전문적인 용어를 쓰거나 일부러 어려운 언어를 사용하는 경우가 있으면 대화하기 싫은것과 마찬가지다.

바로 고객이 느끼는게 그런점이다. 본인이 원하는 요구사항을 이야기하는데 개발자들이 프로그램 언어를 섞어서 쓰면 이해도 안되고 짜증날 수 밖에 없다.

반면 개발자들은 고객이 원하는 요구사항의 배경지식을 충분히 이해해야한다.

도메인이라고 하는데 비지니스에 대한 이해가 없으면 비지니스의 용어 자체를 이해하지 못한다.

유비쿼터스언어는 개발자와 고객, 고객끼리의 소통을 원할하기 위해서 비지니스에 사용되는 언어를 정하는 것이다.

정한 용어를 요구사항에 꼭 사용하고 심지어 개발할 때 이용하여 오해의 소지를 없애는 작업이다.

적당히 잘 나누기와 잘 뭉치기

유비쿼터스 언어를 정의하면서 전체 비지니스안에서 각자의 책임을 가지는 영역을 적당히 나눈다.

이때 사용되는 방법은 이벤트 스토밍이 대표적인데 설명은 안 할거다.

개발자뿐만 아니라 고객들도 직접 참여해서 회의하고 같이 나누는 작업을 하는데 데이터를 기준으로 생각하기도 하고 소유권을 기준으로 생각하기도 한다. 자세한 내용은 DDD와 관련된 교재를 찾아보도록 하자.

비지니스 로직의 경계를 잘 나눴다면 그 경계에 해당되는 것들을 집어넣어서 뭉쳐야한다.

물론 이때도 적당히 뭉쳐야하는게 관건이다. 보통은 트랜잭션을 기준으로 뭉친다. 그리고 뭉친것들중 하나를 대표로 잡아서 출입구 역할을 맡는데 이게 애그리게이트와 애그리게이트 루트이다.

통신을 할 때 이런 출입구를 기준으로 통신하기 때문에 객체지향에서
3. 요구사항에 맞게 경계끼리 통신을 한다.
4. 요구사항에 맞게 튼튼한 통신을 구현한다.
을 자연스럽게 가능하게 한다.

결론

• 유비쿼터스 언어는 오해와 추측이 난무하던 소통의 문제를 해결하여 요구사항의 본질을 명확히 했다.

• 바운디드 컨텍스트는 '책임과 언어'라는 명확한 기준으로 거대한 비즈니스를 '적당히' 나눌 수 있게 해주었다.

• 애그리게이트는 나뉜 경계 안에서 '데이터 일관성'이라는 원칙하에 관련 개념들을 '적당히' 뭉치는 기준을 제시했다.

• 애그리게이트 루트는 이렇게 잘 나뉘고 뭉쳐진 책임의 단위들이 서로의 내부를 침범하지 않으면서도, 명확한 '출입구'를 통해 안전하게 소통할 수 있는 길을 열어주었다.

DDD는 이런 방식으로 객체지향을 잘 설계하게 도와주는 방식이다.