의존성을 이용해 설계 진화시키기
아래 영상을 참조하여 작성하였습니다.
클래스 의존성의 종류
•
연관관계: A에서 B로 갈 수 있는 연관관계가 있다. (영구적)
•
의존 관계: A에서 파라미터, 리턴타입으로 등 B의 인스턴스를 생성하는 경우 (일시적)
•
상속 관계: extends (구현이 바뀌면 영향을 받음)
•
실체화 관계: implements (인터페이스의 오퍼레이션 시그니쳐가 바꼈을 때 영향을 받음)
•
양방향 의존성을 피하라 → 단방향으로!
•
다중성이 적은 방향을 선택해라! → One-To-Many vs Many-To-One
•
의존성이 필요없다면 제거해라
•
관계의 방향 = 협력의 방향 = 의존성의 방향
•
의존성 역전 원칙: 구현체를 직접 참조하는 게 아니라, 상위 요소 (추상 클래스 혹은 인터페이스)를 참조하라는 원칙
•
객체 참조는 결합도가 가장 높은 의존성이다
•
어떤 객체들을 묶고 어떤 객체들을 분리할 것인가?
◦
함께 생성되고 함께 삭제되는 객체들을 함께 묶어라
◦
도메인 제약사항을 공유하는 객체들을 함께 묶어라
◦
가능하면 분리해라
객체 묶기 / 트랜잭션 단위 → 그룹 단위의 영속성 저장소 변경 가능
경계 밖의 객체는 ID를 이용해 접근
•
객체를 직접 참조하는 로직을 다른 객체로 옮기자!
직접적인 도메인간 의존성 분리를 위함
의존성 분리를 통한 로직 모으기
직접적인 의존성
•
때로는 절차지향이 객체지향보다 좋다!!
◦
절차지향
◦
도메인 이벤트 퍼블리싱을 통한 의존성 제거
•
패키지 의존성 사이클을 제거하는 3가지 방법 (양방향 → 단방향)
1.
새로운 객체로 변환
2.
의존성 역전
3.
새로운 패키지 추가
•
도메인 이벤트 사용 전/후의 의존성
◦
전
◦
후
•
도메인 단위 모듈화
시스템 분리의 기반이기 때문에, 분리할 때에도 편리하다 (System Event를 통한 시스템 통합 가능 - 시스템간 통신 가능)
이전의 경험에서는,
순환참조 등과 같은 의존성 문제가 발생하지 않았기 때문에, 의존성 관리를 하지 않았다.
(지금 생각해보면, 그 복잡한 시스템 가운데 어떻게 발생하지 않았는지도 의문이다.)
지금은,
의존성 분리를 위한 interface 레이어 관리를, 영상에서 설명한 도메인간의 이벤트 발행을, 통하여 협력하고 있다.
(물론 도메인이 명확히 구분되어 있는 것은 아니다.)
각각의 도메인은 어떻게 관리되어야 하며, 다른 도메인간의 통신은 어떤 식으로 이루어지며, 어떻게 의존성을 분리하여야 하는지에 대한 좋은 공부가 되었다
