PresentationDomainDataLayering
information-rich 프로그램을 모듈화 하는 일반적인 방법은 presentation-domain-data 3개의 layer로 구성하는 것이다.
이 방법은
1. 한번에 집중해야 할 범위를 줄여준다.
2. UI(Web, Mobile, Console 등) Substitutability 제공
3. Testability(Testing Doubles) 제공
의 잇점을 갖는다. 1번이 제일 중요하고...
최초 domain을 만들고, UI를 만들면서 domain이 변경이 될 수 있고, 이로 인해 data 변경을 유발하는 반복이 발생할 수 있지만, 이것은 래팩토링의 2개의 모자(make it pass / make it clean)와 같은 생각 모드의 전환과 유사한 것이다(필요한 것이고 그리 어렵지 않다는 의미)
FW(Framework)을 이용하면 view-model-data를 최상위 레벨의 네임스페이스(java로 치면 package)로 사용하게 되는 경향이 있다.
이러한 경향은 작은 시스템의 경우는 괜찮다. 하지만 이러한 레이어 중 어느 하나라도 커진다면,
최상위 레벨을 도메인 지향 모듈(domain oriented module. 내부적으로는 3개의 레이어를 갖는)로 분리해야 한다.
Don't use layers as the top level modules in a complex application.Instead make your top level modules be full stack domain oriented modules.
Developers don't have to be full-stack, but teams should be.
3개의 레이어에 따라 팀을 분리하는 것은 안티패턴이다.
이 방법은 FT, Backend 개발자가 서로 다른 FW, 언어를 사용하고, 개발자들이 한두가지의 전문가가 되도록 하기 쉽다는 점에서 매력적으로 보인다.
하지만 레이어 간의 방대한 상호작용은 잦은 인력 교환을 유발한다. 같은 팀에 있다면 자유롭게 협업할 수 있을텐데 말이다.
레이어링과 레이어에 따른 직군/조직에 대한 좋은 글이다. 나는 개인적으로 풀스택 개발자를 지향하지는 않는다. 전문가를 지향하는 편이다. 하지만 같은 조직에 모든 기능을 구현할 수 있는 개발자들이 모두 있는 것은 매우 효과적/효율적이라고 생각한다. 그들이 직군별로 모였을 때 성장하기 쉽다는 것이 이를 현실화하는 것에 대한 큰 숙제이기는 하지만...
