Dev/etc
DDD & TDD
호나우지규
2021. 9. 27. 13:20
Domain
- 일반적인 요구사항, 전문 용어, 그리고 컴퓨터 프로그래밍 분야에서 문제를 풀기 위해 설계된 어떤 소프트웨어 프로그램에 대한 기능성을 정희하는 연구의 한 영역
- 소프트웨어로 해결하고자 하는 문제 영역
Domain Model
- 특정 도메인을 개념적으로 표현한 것
- 도메인 모델을 사용하면 여러 관계자들 (개발자, 기획자, 사용자 등)이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는데 도움이 됨.
- 모델의 각 구성 요소는 특정 도메인을 한정할 때 비로소 의미가 완전해지기 때문에, 각 하위 도메인마다 별도로 모델을 만들어야 함.
- presentation layer
표현 영역 또는 UI 영역.
사용자의 요청을 받아 응용 영역에 전달하고, 응용 영역의 처리 결과를 다시 사용자에게 보여주는 역할
(Controller, DispatcherServlet에게 요청과 응답을 전달) - application layer
응용 영역.
시스템이 사용자에게 제공해야 할 기능을 구현.
Service 영역 - domain layer
도메인 영역.
도메인 모델을 구현
이름, 주소, 상품, 주문서 - infrastructure layer
구현 기술에 대한 것
외부 api, db, library
TDD
test driven devlopement
테스트 주도 개발
테스트를 먼저 만들고 테스트를 통과하기 위한 것을 짜는 것
즉, 만드는 과정에서 우선 테스트를 작성하고 그걸 통과하는 코드를 만들고를 반복하면서 제대로 동작하는지에 대한 피드백을 적극적으로 받는 것
- 보통은 SW 개발을 할때 코딩을 다 끝나고 난 후 테스트 진행
- 이것의 순서를 바꿔서 적용하는 것이 TDD
결정과 피드백 사이의 갭에 대한 인식, 더나아가 결정과 피드백 사이의 갭을 조절하기 위한 기술
TDD 가 필요한 상황
- 만약 어떤 부분에 대한 코딩을 여러번 해봤고 결과가 어떻게 나올지 뻔하다면 TDD 불필요
- TDD를 했을 때 얻는 것이 적다면 TDD를 하지 않아도 됨.
- TDD가 필요한 상황
1. 처음해보는 프로그램 주제 (개발 자체에 대한 불확실성이 높은 경우)
2. 요구사항이 바뀔 수 있는 경우 (외부적인 요소로 인해 자주 바뀔 수 있는 경우)
3. 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
4. 개발하고나서 유지 보수할 담당자가 미정인 경우
* 결론적으로는 불확실성이 높을 떄 TDD
TDD 효과 - 피드백 증가, 협력심
+ 남이 짠 코드나 내가 짠 코드를 다른 사람이 보거나 내가 보아도 테스트를 통해 이해도가 훨씬 빠름