20210817 TIL - Spring (의존성)

Domain Driven Design(도메인 주도 설계)

도메인은 사용자가 어플리케이션을 사용하는 대상영역이 도메인이 된다. (ex. 주문 관리App은 주문관리가 도메인)

 

Entity

• 엔터티는 다른 엔터티와 구별할 수 있는 식별자를 가지고 있고 시간의 흐름에 따라 지속적으로 변경되는 객체
  • 주문 관리App에서는 주문이 엔터티가 된다.
  • 각 Id를 가지고 주문이라는 엔터티를 식별할 수 있다.
  • 가지고 있는 VO인 주문자, 주문아이템, 배송지 등이 바뀔 수 있다.

Value Object

• 값 객체는 각 속성이 개별적으로 변화하지 않고 값 그 자체로 고유한 불변 객체
  • 주문 관리 도메인에서는 주문자, 배송지, 주문아이템 등이 될 수 있다.

    

    출처 : https://www.infoq.com/articles/ddd-in-practice/

     

Spring은 자바 기반 어플리케이션을 만들기 때문에 여러 객체들을 만들게되고, 객체간의 상호작용(의존성)이 생기게 된다.

 

의존성 관리

스프링의 IoC(Inversion of Control) 컨테이너 혹은 DI(Dependency Injection)을 다루기 앞서 먼저 의존성에 대해 알아야 합니다.

 

의존성이란?

어떤 객체가 협력하기 위해 다른 객체를 필요로 할 때 두 객체 사이의 의존성이 존재하게 된다.

의존성은 실행 시점과 구현 시점에 서로 다른 의미를 가진다.

• 컴파일 타임 의존성 : 코드를 작성하는 시점에서 발생하는 의존성. 클래스 사이의 의존성
• 런타임 의존성 : 애플리케이션이 실행되는 시점의 의존성. 객체 사이의 의존성

 

만약 Order라는 객체에서 FixedAmountVoucher 객체와의 상호작용을 통해 어떤 물건의 값을 할인 한다고 하면

컴파일 타임 의존성을 가지게 된다.

그래서 만약 Order가 FixedAmountVoucher를 의존하고 있는데 FixedAmountVoucher 코드가 변경이 일어난다면 기존의Order에도 변화가 일어날 수 있다.

Order에서 FixedAmountVoucher를 사용했을 때

결합도

결합도란 "하나의 객체가 변경이 일어날 때에 관계를 맺고 있는 다른 객체에 변화를 요구하는 정도"라고 볼 수 있습니다.

 

어떤 두 요소 사이에 존재하는 의존성이 바람직할 때 두 요소가 느슨한 결합도 또는 약한 결합도를 가진다고 말합니다.

반대로 두 요소의 의존성이 바람직하지 못할 때 단단한 결합도 또는 강한 결합도를 가진다고 말합니다.

 

위의 상화을 런타임의 의존성을 가지게 하려면 Order가 FixedAmountVoucher를 의존하지 않고 Voucher란 Interface를 사용할 수 있도록 한다.

 

그러면 Order 입장에서는 할인하는 것만 알게 되고, 어떤 Voucher 이용하는 지는 모른다.

그래서 만약 FixedAmountVoucher가 아닌 PercentAmountVoucher가 구현한 할인 방법에 대해서 사용을 하려면 Order 클래스의 코드가 변경될 필요 없이 런타임중에 PercentAmountVoucher객체를 전달해주면 된다.

 

이런 경우를 "결합도가 낮다, 런타임의 의존성을 가지게 된다" 라고한다.

 

Voucher 인터페이스를 사용