kkoon9

🤔 DTO와 엔티티 중 validation을 어디에 걸어야 할까? DDD를 도입하는 초기 단계여서 그런지 위같은 질문이 계속해서 들었다. 책에서 배운 걸 떠올렸을 때에는 다음과 같다. 타입에 대한 검증은 컨트롤러 이전인 DTO에서 처리되어야 한다. 비즈니스적인 유효성 검증은 domain 엔티티에서 처리되어야 한다. 하지만 아래 나와있다시피 비즈니스 규칙을 검증하기가 여의치 않다면 도메인 엔티티 사용전에 사용해도 된다. 그래서 결론을 내린 게 입력명 길이나 필수값을 DTO에서 처리하기로 했다. 다음은 상점을 만드는 DTO 예시 코드와 같다. import lombok.Builder; import lombok.Getter; import net.logstash.logback.util.StringUtils; im..

수영 기록을 위해 해당 월에 대한 주(weekOfMonth)를 알아야 했다. calendar Table DDL 그러기 위해 날짜와 주를 가지는 Calendar 테이블을 생성하였다. create table calendar ( id int auto_increment primary key, date date not null comment '날짜(YYYY-MM-DD)', week int not null comment '해당 달의 주차', created_at timestamp default CURRENT_TIMESTAMP not null ) comment '달력 테이블'; 위 테이블에 마이그레이션을 위해 python script를 작성하였다. 규칙 해당 월에 주를 구하기 위해서는 다음과 같은 규칙을 알아야 한다...

프로젝트 때 사용한 branch 전략 톡딱 팀 서버파트에서 사용한 branch 전략은 잘 알려진 git flow보다는 간략하게 구성했습니다. master : 제품으로 출시될 수 있는 브랜치 develop : 다음 출시 버전을 개발하는 브랜치 feature : 기능을 개발하는 브랜치 각자 feature 브랜치를 추가하여 기능 개발 후 develop에서 merge하여 push하는 방식으로 진행했습니다. 간략하게 구성한 이유는 저 포함하여 팀원 모두가 협업은 처음이었기 때문입니다. pull request 사용에 미숙한 점도 있었고 그로 인한 충돌이 개발 시간을 많이 잡아먹을 것으로 판단하여 간략하게 구성해봤습니다. 문제점 : 커밋 그래프의 복잡함 rebase를 해야 커밋 그래프를 단순화시킬 수 있다! reba..