1] 서론

최근에 DDD를 공부하고 자바/스프링 개발자를 위한 실용주의 프로그래밍이라는 책을 보면서, 결국 Java를 이용한 객체 지향적 프로그래밍은 DDD를 구현하는 것이 필수라는 생각이 들었습니다.

도메인 로직을 코드에 잘 녹여야 된다는 말과, 책임을 객체에게 지운다는 것, 결국은 도메인 모델링을 통한 DDD를 적용한다는 말과 동일하다는 것이죠.

물론 토이 프로젝트나 MSA의 구조에서는 애자일하게 빠르게 개발하기 위해 전통적인 방법인 technical responsibility에 따라 package 구조를 나누는 것 또한 좋은 방법이지만, 프로젝트의 크기가 커지거나 Monolitic한 구조로 간다면, 굉장히 많은 도메인 지식들을 외우거나 문서 작성을 통해서 프로젝트를 유지하는 것은 굉장히 어렵다고 생각합니다.

이런 도메인 지식들을 모두 문서화해서 최신화하는 것은 30개의 다른 도장들을 들고 다니는 일본 기업이라면 가능할지도 모르지만, 그렇다고 해서 '그것이 더 좋은가?'에 대해 생각해 볼 때, 더 편하고 쉬운 개발은 아니라는 것이죠.

최근 업무에서 한 컬럼에 대한 유효성이 추가되는 요구사항이 있어 구현하였는데, 저희 프로젝트는 유효성 체크를 메서드 안에 넣는 구조로 되어 있었습니다.

그래서 해당 컬럼의 테이블을 생성하거나 해당 컬럼을 수정하는 메서드를 모두 찾았고, 각 메서드의 유효성 체크 로직에 로직을 추가하면서 든 생각은 '해당 테이블의 생성자에 넣으면 안되나?'였습니다.

사실 원래 해당 객체를 invalid한 상태로 두는 것을 허용해선 안되죠.

이러한 것들이 모이면서 저는 객체 지향적으로 짜는 코딩을 하고 싶었고, 객체 지향의 극의는 도메인 모델링을 통한 개발이라고 생각했기 때문에, '과연 진짜 DDD를 구현하였을 때 코드 구현이 더 쉬워지는가?'에 대한 답을 내리고 싶었습니다.

또한 저는 '한번 쓰고 버리는 프로젝트가 아닌 이상, 계속 develop하는 프로젝트인 이상 Monolith 구조에서는 무조건 DDD가 은탄환이다'라는 생각도 증명하고 싶었습니다.(물론 빠르게 서비스를 개발하여 시중에 배포해야 되는 프로젝트라면, 절대 해서는 안된다고 생각합니다.)

그리고 변덕적인 클라이언트의 요구사항을 모두 받아주고 싶기도 했습니다. 어떠한 요구사항도 들어주고 싶었습니다. 그게 제 일이라고 생각했기 때문입니다. 쉬운 일이라면, 누구든지 할 수 있는 일이라면 그것은 목표를 삼고 보상을 얻는 challenge가 아닌 단순 노동이라고 여기기 때문입니다.

그렇기 때문에 이 Toy Project를 시작하였습니다. 도메인은 저희 회사의 것을 할 수는 없고, 비슷한 금융업인 은행으로 정했습니다.

DDD로 해당 프로젝트를 진행하게 되었을 때, 과연 모든 요구사항을 구현해 줄 수 있는지, 유지보수 할 때에 더 쉬운지, 불편함은 없는지, 은탄환이 될 수 있는지를 체크해볼 계획입니다.

또한 지금까지 제가 배운 것들을 모두 적용시켜 보면서 배운 것들을 복습하는 면도 있습니다.

일정은 Jira를 통해 관리할 것이고 기간은 24년 연말까지 완성 예정입니다.

감사합니다.

2] Jira 설정

1. 이슈 유형 설정

Jira Space를 만들고, 프로젝트의 이슈 유형을 설정해 주었습니다.

기본 사항으로는 에픽과 작업, 하위 이슈 밖에 없기 때문에 Jira 이슈 개요를 참고하여 다음과 같이 이슈 유형을 추가하였습니다.

QA도 넣을까 했는데, Task 안에 하위 작업으로 QA를 넣는 것이 좋다고 판단했습니다.

또한 모든 이슈들은 다음과 같은 필드를 만들어서 관리하였습니다.

3] Design Bank

아직 은행에 대해서 어떻게 구성할지 디자인하지 않았기 때문에, Bank를 디자인하는 작업을 Epic 이슈로 등록하였습니다.
이 이슈에서 은행을 디자인할 때에 어떤 것을 해야 되는지에 대한 각각의 Epic을 만들고 공수를 산정할 예정입니다.
또한 만든 Epic마다 하위 단계의 이슈들을 설계하려고 합니다.

---

Next Plan

Design Bank 이슈 해결