프로젝트 정리 중에, Tree-Layered 방식의 설계와 Graph-Module 방식의 설계에 대해 각각의 장단점을 좀더 깊이 생각해보고 있다.

...
모듈은 하나의 수정이 다른 수정에 (코드상으로) 영향을 미치지 않기 때문에 OpenClosed 원리를 잘 만족한다. 인터페이스 영향이 적고 서로 독립적일 가능성이 높기 때문에 개발시 중복이 많이 발생할 수 있으나 모듈 개발의 속도가 높을수 있다.
...

응집도와 확장성이라는 두가지 가치추구에 있어서, 현재의 프로젝트는 확장성에 많은 가치를 둔다. 사실 이러한 성향은 코드의 복사를 어느정도 허용하느냐에 대한 이야기와 어느정도 이어져 있다. 요상한 합집합 객체를 만들정도로 코드의 복사를 싫어하는 나는 그래서 대부분의 개발에서 레이어드 디자인을 선택한다.

산탄총 수술과 정책의 적용

코드 복사를 싫어하는 이유는 여러가지가 있다. 여러곳에 같은 역할을 하는 정보가 있는것 자체도 싫지만, 같은 역할에 대해 하나의 변경이 모두에게 미치지 않아 산탄총 수술을 해야하는 상황은 정말 고단하다 - 심지어 복사되어 성장해 버린 코드는 어디에 산탄이 박혀 있는지도 찾기 힘들다.

특히 이러한 코드가 정책과 관련되어 있다면, 일관성 없는 정책 적용때문에 바로 버그로 나타날 것이다. 버그 발생 주요 원인에서 살펴봤을 때도 이러한 버그가 20%에 육박했었다.

TL;DR

레이어드 디자인과 모듈 디자인에 대한 글의 결론은 다음과 같다.

...
따라서, 언제 일괄적인 정책적용등의 높은 응집도가 필요하고 언제 확장적인 독립적 개발과 수정이 필요한지 잘 판단하여 적절한 아키텍쳐를 적용해야 한다.

사실 나는 레이어드 디자인을 훨씬 더 선호하지만, 상황에 따라서는 독립적 개발이 필요하여 모듈 방식이 더 적합한 부분 또한 존재 할 것이다. 다만, 정책 적용과 관련된 부분에서 코드 중복이 발생한다면, 그것이 구조적으로 동등하지 않은 모듈에서 기인한것인지 좀더 꼼꼼히 따져볼것이다.