프리코스 3주차 과제
프리코스 3주차에서 배운점
3주차에 들어오며 많은 코드 리뷰를 하였고, 사람들이 MVC가 아닌 DDD를 사용하는 것을 알 수 있었다. 그래서 이에 대해 찾아보고 적용하게 되었다.
DDD(Domain-Driven Design)
DDD에서 말하는 Domain은 비지니스 Domain을 의미하고 이는 유사한 업무의 집합을 의미합니다. 즉 DDD는 Domain 별로 나누어 설계하는 방식인것입니다.
DDD의 핵심 목표는 결합도는 낮추고, 응집도를 높이는 것에 있습니다.
이번 주차에서는 한가지의 업무 만이 아닌 관련된 모든 업무를 하나의 클래스로 묶어서 진행하였는데, 이는 좋지 않은 방식이였던 것 같으며, 이번 주차를 진행하여 이번에는 철저히 분리하였습니다.
저번 주차에서 Validation 메서드는 view 패키지에 넣어 책임지는 로직과 최대한 가까이 붙었으나, DDD에서는 domain에서 그 역할을 해야 한다고 하여 Domain에서 그 역할을 가지게 되었습니다.
service와 DTO도 있는데 service는 하나 이상의 도메인 객체를 엮어 비지니스 로직을 수행하는 것이고, DTO는 계층 간의 데이터 전달을 위한 객체로 도메인 모델을 직접 노출하지 않고 필요한 데이터만 전달하는 역할을 합니다.
테스트 코드
feedback이나 DDD를 공부하며 찾은 바로는 입력 로직이나 출력 로직에 대한 테스트를 진행할 필요는 없다고 한다. 너무 간단한 로직, 연산 과정 없이 단순한 입/출력,의 경우 굳이 테스트 케이스를 작성할 필요가 없다고 한다.
그리고 기존에는 @Test 데코레이터를 사용하여 Test 케이스를 작성하였는데, @ParameterizedTest 데코레이터를 발견하였다. 이는 Source를 지정하여 하나의 테스트 메서드를 입력 값을 바꾸어 여러 번 테스트 하는 것이다. 이를 통해 경계값 분석으로 코드를 더 철저하게 테스트 하는 것이 용이해졌다.
7기와 미교하여 성장한 점
MVC
이 당시에 MVC를 적용하려던 흔적을 발견하였다. 하지만 Controller에는 관련 코드가 없고, 패키지를 건들면 안되는 Application과 model에 있어야 하는 lotto 클래스가 존재하였다. View는 너무 많은 기능들을 책임지고 있었고, validation 메서드는 따로 빼지 않았다.
재입력 로직
문제에서 에러가 발생한 지점부터 재 입력할 것을 요구하였으나, 코드를 심플하게 만들기 위해 다시 처음부터 입력하게 만든 것 같다.
README
확인해보니 README은 거의 건들지 않아 코드 리뷰하기 힘든 것 같다. 정리 해둔 것을 보니 모든 컨벤션을 지키려 한 것이 아닌 본인이 이해한 것만 지키려고 한 것이 보인다.
최종 후기
다음 주가 기사 시험이기에 많은 것을 적용하지 못하였고, 최대한 해야하는 것은 반드시 지켜려 노력했다.