스택을 장악해 고객에게 진정한 부가가치를 제공하라
Source: Dev.to
Part 1 — Owning the Stack Starts with the Domain
(이 글이 다소 길어져서 3개의 파트로 나누었습니다)
많은 이른바 “맞춤화(customization)”는 실제로 UI 가장자리를 만지는 수준에 불과합니다. 프로젝트는 종종 실패 운명을 타고, 여러분은 타이타닉의 갑판 의자를 재배열하고 있는 셈이죠. 진정한 맞춤화와 고객에게 가치를 제공하려면, 실제 가치가 존재하는 스택의 깊은 곳, 즉 도메인 레이어에 들어가야 하며, 적절한 제어를 위해 더 깊이 파고들어야 합니다.
The Software Stack (layered view)
- Infrastructure layer – 데이터, 호스팅, 통합
- Platform layer – 모델을 시스템으로 전환시키는 가속기
- Domain layer – 비즈니스 모델 및 규칙
- Application layer – 워크플로, 프로세스, 오케스트레이션
- Experience layer – 맞춤 UI, 대시보드, API
고객이나 내부 팀을 위해 소프트웨어를 만든다면, 다음과 같은 패턴을 보았을 것입니다:
- UI는 매년 바뀐다
- 기술 스택은 몇 년마다 바뀐다
- 비즈니스 규칙은 어떻게든 영원히 살아남는다
대부분의 시스템은 도메인을 사후 고려사항처럼 다룹니다.
Why the Domain Layer Matters
도메인 레이어는 실제로 중요한 부분입니다. 이것이 바로 고객에게 차이를 만들고, 가장 큰 부가가치를 제공할 수 있는 영역입니다.
도메인 레이어는 다음으로 구성됩니다:
- 비즈니스 개념
- 규칙 및 제약조건
- 정책 및 불변조건
- 데이터의 의미
고객과 함께 화이트보드에 서서 그들의 비즈니스 컨텍스트를 정의하고, 고객이 실제로 신경 쓰는 용어로 작업하는 곳이 바로 여기입니다. 시스템의 이 한 부분은:
- 재작성에도 살아남는다
- 프레임워크를 초월한다
- 소프트웨어가 올바른지 여부를 정의한다
만약 여러분의 도메인이:
- 컨트롤러에 흩어져 있다
- UI 흐름에 하드코딩되어 있다
- 데이터베이스 스키마에 암묵적으로 존재한다
- 특정 벤더의 데이터 모델에 고정돼 있다
…라면, 여러분은 시스템을 진정으로 소유하고 있지 않은 것입니다. 현재 작동하는 형태를 유지하고 있을 뿐입니다.
Owning the Domain
도메인을 소유한다는 것은 다음을 할 수 있음을 의미합니다:
- 의미를 바꾸지 않고 UI를 변경한다
- 비즈니스 로직을 다시 작성하지 않고 인프라를 교체한다
- 핵심 규칙을 깨뜨리지 않고 워크플로를 추가한다
- 코드 경로가 아니라 비즈니스 용어로 시스템을 설명한다
다시 말해: 도메인은 고객의 실제 IP와 같습니다. 이 레이어를 소유하지 않으면 시스템을 구축하는 것이 아니라 단순히 맞춤화하고 있는 셈입니다. 나머지는 모두 전달 메커니즘에 불과합니다.
First Step to Owning the Stack
툴, 플랫폼, 프레임워크에 대해 생각하기 전에, 도메인을 명시적이고, 일관되며, 독립적으로 만들세요. 도메인 레이어는 프레임워크, UI 재작성, 인프라 변화보다 오래 살아남아야 합니다. 명시적이고 깔끔하며 독립적이라면, 시스템은 영혼을 잃지 않고 진화할 수 있습니다. 그렇지 않다면, 여러분은 보통 “대규모 리팩터링” 한 번만으로도 우연한 재작성과 규칙 파괴에 직면하게 됩니다.
Question: 현재 여러분의 비즈니스 로직은 어디에 존재하나요 — 도메인 레이어에 깔끔하게 정리돼 있나요, 아니면 컨트롤러, UI 흐름, 데이터베이스 스키마에 흩어져 있나요?
Next in Part 2: To bring true value to the client in the Domain Layer, you need control of the key development piece – the Platform Layer – and that’s where real leverage lives.