아키텍처 구성 후,
외부 업체의 개발 생산성을 이유로
외부 업체 자체 프레임웍을 내가 설계한 아키텍처에 붙였습니다.
내가 보기에 아주 조잡하고 맘에 안들어서 반대를 했지만, 내 능력 밖이였습니다.
반대하는 과정에서 팀장님과 약간의 언쟁(?) 이 있었습니다.
외주 업체 자체 프레임웍이라는게 데이터베이스와 연결하여 도메인 클래스를 만들어주고,
기본적인 CRUD 는 자동으로 처리해주는 것 이였습니다.
내가 이 자체 프레임웍이 맘에 안드는 이유는
첫째, 자동생성된 도메인 클래스가 아주 맘에 안들었습니다.
자동생성된 도메인 클래스
자동생성된 도메인 클래스는 위 그림과 같았는데,
DDD를 추구하던 나로써는 아주 보기가 좋지 않았습니다.
그런데 팀장님이 이게 왜 나쁜건지 설명해보라고 하니, 설명을 제대로 하지 못했고, 쓸데없는 소리만 주절댔습니다.
그런 내자신에 무척 화가 났었습니다..
둘째, 조인된 쿼리에 대한 결과를 List<Map> 으로 가져옵니다.
마찬가지로 DDD를 추구하던 내 입장에서 List<Map> 형태로 결과를 가져온다는건 큰 불만이였지만, 이 역시 설득할 수 없었습니다.
설득하는 과정에서 DDD에 대해서 이야기 했지만, 내가 듣기에도 내가 하는 이야기는 횡설수설하고 원론적인 이야기뿐이였습니다.
IDE (이클립스, INTELLIJ) 기능을 이용하여 데이터베이스와 연동하여 도메인클래스를 생성하는 방법에 대해서 이야기를 했지만, 묵살되었습니다.
결국, 외주업체의 자체 프레임웍이 도입되었습니다.
최종적으로 가장 맘이 아팠던건
내가 추구하던 DDD를 다른사람에게 설득시키지 못했던 점이고, 지금도 말로 설득시킬 자신이 없습니다.
개인적으로, 남에게 정확하게 설명할 수 없다면 나도 100% 이해한게 아니라고 생각합니다.
또,
팀장님과 이야기할때,
도메인클래스에 위 이미지와 같이 각종 static , 배열, 데이터베이스 정보가 들어가있는게 좋지 않다 .
라고 이야기를 했었는데 팀장님이 왜? 왜 좋지않은데? 라고 물어보니 말문이 확 막혔습니다.
남을 설득하는것도 타이밍이라는게 있어서 그 시점에 설득력이 없으면,
다음 시점에는 상대가 잘 들으려 하지 않더군요
좀 더, 공부하고 내공을 쌓아야겠습니다...