설계 원칙

소프트웨어 아키텍처의 목표는 무엇인가?

생산성을 극대화하기 위함이다. 그렇다면 생산성을 극대화 한다는 것은 무엇을 의미하는가? 변경에 유연하고, 기능을 확장할 수 있어야한다.

그렇다면 어떤 코드가 변경에 유연해야하고, 어떤 코드가 확장되어야할 코드일까? 그러니까 어떤 영역을 우리는 지켜야 할까? 바로 우리의 도메인 영역이다.

도메인 영역을 잘 지키기 위해서는 어떻게 해야할까?

OCP

OCP 는 이런 관점에서 중요한 설계 원칙이다.

기존 코드의 변경없이, 기능을 확장할 수 있어야한다. 그렇다면 이것은 어떻게 가능할까?

OCP는 단순히 다형성만으로 설명할 수 있는 개념은 아니다. 아키텍처 관점으로 볼때, OCP가 잘 이루어지기 위해서는, 컴포넌트와 모듈은 응집력있고, 컴포넌트와 모듈의 결합은 낮아야한다.

이것을 가능하게 하기 위해서는 SRP와 DIP 가 전제되어야한다.

결론적으로는, SRP와 DIP 를 잘 지키지 않으면 응집도가 낮아지고 결합도가 높아져서 변경에 취약한 아키텍처가 될 수 밖에 없다.

SRP

SRP는 단일 책임 원칙으로, 변경의 이유는 하나 단 하나여야 한다는 것을 의미한다. 모듈이 단일 책임 원칙을 지키면 아래가 가능해진다.

1. 하나의 모듈에 여러 기능이 모여있지 않다.
2. 여러 모듈의 하나의 기능이 퍼져있지 않다.

하나의 모듈에 여러가지 기능이 모여있다면, 모듈에서 특정 기능을 수정하면 그 수정으로 다른 모듈들도 수정이 필요하다. 왜냐하면 여러 다른 이유로 다른 모듈들이 해당 모듈을 의존하고 있기 때문이다.

또한, 여러 모듈에 하나의 기능이 퍼져있다면, 수정시 퍼져있는 기능들을 수정하기 위해서 찾아다녀야 할 것이다.

그렇기 때문에 기능을 추가하거나, 수정할 때 변경의 영향이 의존성을 타고 연쇄적으로 이어지게 된다. 그러면 하나의 변경사항으로 인해 여러 모듈들이 수정되어야 하게 된다.

예를들어, 통신 layer에서 통신과 관련된 것들을 제대로 처리하지 않고, 인자로 Http에 관련된 인자를 그대로 도메인 영역으로 전달하면 어떻게 될까?

http 통신이 아니라 rpc 통신 혹은 이벤트 통신으로 변경된다면 변경의 범위는 통신 layer 외에 다른 곳들로 퍼져 나가게 된다. 즉, 통신 layer의 기능이 도메인 영역으로 퍼지게 되는 것이다.

DIP

의존성 역전 원칙으로, 코드의 실행 흐름(제어 흐름)과는 다르게 코드의 의존성이 설계 되는 것을 의미한다.

왜 이것이 필요로 한가에 대해서 생각해보면, 우리가 생각하는 중요한 객체가 어떤 객체에 직접 의존하게 되면 해당 객체의 변경에 쉽게 영향을 받는다.

물론, 그것이 쉽게 변하지 않으리라 예상한다면 직접 의존해도 된다. 하지만, 변동성이 큰 객체라면, 우리는 그것을 직접 의존하지 않아야한다.

인터페이스는 구체 클래스에 비해 비교적 안정적이다. 그렇기 때문에 인터페이스에 의존할 수록 변경에 영향을 적게 받는다. 즉, 결합도를 낮출 수 있게 된다.

추상화에 의존하지 않고, ORM 코드를 그대로 import 해서 사용한다면 어떻게 될까? ORM을 변경하게 되면, 그것의 여파가 도메인 코드에도 그대로 결합되어 있어 변경하기가 어려워진다.

ORM을 쉽게 변경하나요? 라고 묻는다면, 물론 자신의 제품이 얼마나 갈지 알 수 없지만, MyBatis에서 JPA, sequelize에서 typeorm 등으로 대세가 이동하는데는 그리 오래 걸리지 않았다. 심지어 필요에 따라 RDB에서 NoSQL 로도 이동할 수 있다.

응집도와 결합도?

응집도를 잘 지키지 않으면, 기능을 추가하거나 수정할 때 여러 모듈들을 찾아다니며 수정을 해야하는 상태가 되는 것이다.

반면, 결합도는 하나의 모듈을 수정하면 이를 의존하는 모듈이 하나의 모듈 수정으로 인해, 같이 수정되어야 하는 것이다.

두가지가 잘 지켜지지 않으면, 변경에 유연하지 못하게 되는 것이다.