DDD(도메인 주도 개발)란?
Domain-Driven Design의 약자로 '도메인 주도 개발' 또는 '도메인 주도 설계'라고 부른다 도메인 패턴을 중심에 놓고 설계하는 방식을 일컫는다
특징
- 도메인 그 자체와 도메인 로직에 초점을 맞춘다. 일반적으로 많이 사용하는 데이터 중심의 접근법을 탈피해서 순수한 도메인과 모델과 로직에 집중하는 것을 말한다.
- 보편적인 언어의 사용이다. 도메인 전문가와 SW 개발자 간의 커뮤니케이션 문제를 없애고 상호가 이해할 수 있고, 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나가는 과정을 말한다.
이로서 분석 작업과 설계 그리고 구현에 이르기까지 통일된 방식으로 커뮤니케이션이 가능해진다.
-소프트웨어 엔티티와 도메인 컨셉트를 가능한 가장 가까이 일치시키는 것이다. 분석 모델과 설계가 다르고 그것은 코드가 다른 구조가 아니라 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향하는것이 DDD의 핵심원리다.
데이터 주도 설계란?
데이터 주도 설계란 객체가 가져야 할 데이터에 초점을 두고 설계하는 방식을 말한다.
데이터 주도 설계에서는 객체 자신이 포함하고 있는 데이터를 조작하는데 필요한 행동을 정의한다.
사용 목적
- 도메인 모델의 적용 범위를 구현까지 확장하여 도메인 지식을 구현 코드에 반영한다.
- 공통의 언어를 사용하여 도메인과 구현을 충분히 만족하는 모델을 만든다
- 실제 코드로 구현 가능한 현실성 있는 도메인 모델 분석과 그것을 추상화하는 설계이다.
TDD(테스트 주도 개발)란?
Test Driven Development의 약자로 '테스트 주도 개발' 이라고 한다.
테스트 주도 개발 (TDD)는 설계 이후 코드 개발 및 테스트 케이스를 작성하는 기존의 개발 프로세스와는 다르게 테스트 케이스를 작성한 후 실제 코드를 개발하여 리펙토링하는 절차이다.
특징
장점
위에서 언급한 바와 같이 원할한 피드백과 협력을 증진시킬 수 있다.
또한 테스트 코드가 독립을 이루면서 다른 사람들과 공유가 쉬워진다. 그리고 이해가 빨라지며, 다른사람의 코드 의도를 빠르게 확인이 가능하다. 이외에도
보다 튼튼한 객체 지향적인 코드 생산
- TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄진다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 된다.
재설계 시간의 단축
- 테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 된다. 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있다. 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.
디버깅 시간의 단축
- 이는 유닛 테스팅을 하는 이점이기도 하다. 예를 들면 사용자의 데이터가 잘못 나온다면 DB의 문제인지, 비즈니스 레이어의 문제인지 UI의 문제인지 실제 모든 레이러들을 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있다.
테스트 문서의 대체 가능
- 주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만든다. 이것은 단순 통합 테스트 문서에 지나지 않는다. 하지만 TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.
추가 구현의 용이함
- 개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.
단점
가장 큰 단점은 바로 생산성의 저하이다.
- 개발 속도가 느려진다고 생각하는 사람이 많기 때문에 TDD에 대해 반신반의 한다. 왜냐하면 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문이다. TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어난다.
- SI 프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않는다.
TDD의 사용목적
- 불확실성이 높을 때 "피드백"과 "협력"이 중요하기 때문에 피드백과 협력이 자주 이루어 진다면 더 좋은 결과가 나올 수 있다.
만약 특정 부분에서 코딩을 여러번 해봤고 결과에 대한 숙지가 완벽하다면 TDD를 하지 않아도 된다.
또한 TDD를 했을 때 얻는 것이 적다면 TDD를 하지 않아도 된다.
하지만
-
익숙하지 않은 프로그램 주제
( 나에 대한 불확실성이 높은경우 ) -
고객의 요구조건이 바뀔 수 있는 프로젝트
( 외부적인 불확실성이 높은경우 )
-
개발하는 중에 코드를 많이 바꿔야한다고 생각하는 경우
( 전체적인 불확실성이 높은경우 ) -
개발 이후 이 코드를 누가 유지보수할지 모르는 경우
즉, 불확실성이나 변동성이 높은경우 사용하면 피드백과 협력은 동시에 증진시키므로 업무의 대한 정확성이 높아진다.
References (참고 자료)
