loosely coupled, highly cohesive

프로그램 설계를 잘 하기위해 추상화, 모듈화, 구조화 등 무수히 많은 원칙과 기법이 있을 것이다. 그 많은 원칙과 기법 중 딱 하나만 남기라면 어떤게 좋을까? 나는 망설이지 않고 이것을 선택할 것이다.

 

Loosely coupled, highly cohesive (이하 LCHC)
연관성이 높은 것끼리는 응집도가 높고, 관련 없는 것들은 결합이 아예 없거나 있어도 느슨해야한다. 딱 떨어지지지는 않지만 연관된 표현으로 Single responsibility, Data ownership 도 있다. 응집도 높게 묶인 집합은 한가지의 단일 목표에 대한 책임을 갖고(Single responsibility), 그 목표에 맞는 데이터만 가져야한다. (Data ownership)

 

시스템을 어떨까 나눌까?, Microservice를 어떤 단위로 분리 또는 통합할까? 하는 고민에도 LCHC가 우선되어야 한다. 시스템 뿐아니라 회사 조직도 LCHC 여야한다. 여러 파일을 묶어 폴더로 관리할 때도 연관없는 파일은 다른 폴더로 관리하는데 LCHC 다른 것은 당연하지 않겠는가?

 

데이터모델링 ERD를 그릴 때에도 하나의 Entity에 수십, 백여개의 Attribute가 있다면 LCHC를 고민해야 한다. 지금 정의하고 있는 Entity와 관련없는 속성이 있는건 아닌지, N:N or 1:1 Entity로 분리할 것은 없는지, 결국 LCHC다.

 

누가 묻는다. 컴포넌트 하위에는 어느정도의 Operation(Method)을 갖고 있어야 적당하냐고...
정답은 LCHC다. 연관성 있는 Operation끼리 하나의 컴포넌트(클래스)에 묶여 있다면 괜찮고, 한두개라도 연관성 없는 것 끼리 묶여 있다면 틀린 것이다.

 

Module이나 Package를 적절히 분리, 통합할 때의 기준도 LCHC다.

 

누가 그랬다. 모델링에 정답은 없지만 오답은 있다고.

그 오답인지 아닌지의 기준이 결국 큰 틀에서는 LCHC다.