도메인주도 설계 철저 입문 - 값객체, 엔티티, 도메인 서비스 그리고 의존관계

개발자를 막 시작하던 시기에 적절한 자료구조와 알맞은 알고리즘만 사용할 줄 알면 
괜찮게 만든다고 생각한 적이 있다. (아예 틀린 말은 아니지만.)

지내고 보니 위 생각은 기계쪽(?) 치우친 생각이었고 사람과 일하려면 도메인 파악이 중요하다는 것을 느낀다.

서비스의 도메인을 이해하고 개발을 해야 쏟아지는 다양한 요구사항들을 신속하게 대처할 수 있고
이는 결국 개발자의 생산성과 이어진다.

 

요즘 엔티티 정의를 어떻게 해야 잘할까...고민이 있어 집어 들었다.

 

값 객체

대표적인 값의 성질

• 내용은 변하지 않는다. (변하는건 값이 아닌 변수의 내용)
• 주고받을 수 있다.
• 비교할 수 있다.

원시 타입에 익숙한 개발자는 값 객체 표현을 위해 클래스가 많이 생성되는 것을 보고 껄끄러워하는 경우도 있다.

그래서 소개한다. 값 객체의 장점!!

• 표현력이 증가한다.
• 무결성이 유지된다.
• 잘못된 대입을 방지한다.
• 로직이 이곳저곳에 흩어지는 것을 방지한다.

나도 초반에는 클래스가 많아지는 것에 껄끄러웠는데 마지막 장점으로 값 객체를 쓰려고 노력한다.
껄끄러운건 이름을 어떻게 지을지 인 듯... VO? DTO? Response?

 

엔티티

엔티티는 도메인 모델을 구현한 도메인 객체다.

값 객체도 도메인 모델을 구현한 도메인 객체다.

두 가지 객체의 차이는 동일성을 통해 식별 가능 여부에 있다.

 

사람은 이름, 키, 체중, 나이 등 다양한 속성을 갖고 이 값들은 여러 가지 요인에 의해 변한다.

그러나 값이 변한다고 해서(키 크거나 나이를 먹거나)

어떤 한 사람이 다른 사람으로 변하지 않는다.

 

어떤 한 사람이 그 사람이 되는 이유는 속성과는 무관하며

동일성을 지켜주는(userId) 무언가가 있다는 것을 보여주는데

시스템에서는 동일성이 있으면 엔티티, 없으면 값객체라고 생각하면 된다.

 

엔티티의 성질

• 가변이다.
• 서로 다른 두 엔티티의 속성이 같아도 구분이 가능하다.
• 동일성을 통해 구별된다.

값 객체도 되고 엔티티도 될 수 있는 모델

타이어를 예를 들어보자.

타이어는 자동차를 구성하는 부품이어서 값 객체로 나타내기에 적합한 개념이다.

하지만 타이어 공장의 타이어는 언제, 어디서 만들어졌는지 식별하는 것이

중요하기 때문에 엔티티가 적합하다.

같은 대상이라도 어떤 환경에 있느냐에 따라 모델링 방법이 달라진다.

 

도메인 서비스

소프트웨어에서 말하는 서비스란 클라이언트를 위해 무언가 해주는 객체를 말한다.

값 객체나 엔티티에 행동을 정의할 수 있는데 중복 체크처럼 도메인 모델에 정의하기 어색한 경우 서비스가 대신해줄 수 있다.

그렇다고 모든 행동을 서비스에 넣어버리면 빈혈 도메인 모델이 되므로 주의해야 한다.

 

의존관계제어

프로그램에는 추상화 개념이 있는데 입출력으로부터의 거리를 뜻한다.

추상화 수준이 낮다는 얘기는 기계와 가까운 구체적인 거기를 뜻하며

추상화 수준이 높다는 얘기는 사람과 가까운 추상적인 처리를 말한다.

 

추상 타입이 세부 사항에 의존하도록 구현하면 낮은 추상화 수준의 모듈에서 발생한 변경에도

높은 추상화 수준의 모듈이 영향받는다.

변경사항이 많은 곳에 퍼지지 않도록 응집도 높게 구현하고 추상화 수준이 높은 모듈과 의존 관계를 맺도록 하자.

(그렇다고 모든 걸 추상화하려는 것도 과하다... 오랜 기간 인터페이스 하나에 구현한 객체 하나인 경우도 봄)

개발할 때 객체 간의 의존관계를 막을 수는 없지만 방향성은(추상화 높은 모듈이 추상화 높은 모듈에 의존) 개발자가 제어 가능하다.

 

추상적, 구상적 사고

https://news.hada.io/topic?id=10378