[개발생각] toString()과 toInt()의 비교 순서에 대해서
작은 차이가 명품을 만든다.. 어느 광고 카피가 생각난다. Int형 userId변수가 있고, string형 userIdStr변수가 존재하는데,이 두개의 값 자체는 정수값으로 같고, 타입만 틀린상태라고 해보자.이 두 변수를 비교해서 처리하는 로직이 아래와 같이 코딩되었다고 가정하면, if (userId.toString() == userIdStr) { //비즈니스 로직} else { //비즈니스 로직}이 코드가 잘 짜여진 코드일까? 생각해보자.. 단연코, 나는 아니라고 생각한다. 엄청 심플한 코드 같지만, 정말 세밀한 차이로 코드의 퀄리티가 달라질수있다.위의 코드는 아쉽지만, 잘못 짜여진 코드라고 생각한다.userIdStr은 String형 타입, 문자열이기에, userIdStr안의 값이 정수값인지, ..
[개발생각] 도메인VO를 컨트롤러의 입력파라미터로 써도될까?에 대한 고민
개발자의 욕심은 끝이 없으니, 재사용, 재사용이라는 프레임에 갇히고, 또 의미를 잃어버리고... 도메인VO를 정의할때, 대부분 그냥 Value Class (코틀린)로 정의해서 사용한다.즉, 대부분은 단순 Wrap 클래스로만 VO를 정의하고 사용한다. 타입 안정성과 명시적 의미부여에 큰 의미를 둘 수 있기에, Wrap 클래스 정도만이여도 상당히 강력하다고 생각하기 때문이다.하지만, 좀더 서비스가 복잡해지고 방대해 진다면, (즉, 다뤄야하는 도메인이 많아진다면)VO가 다양해지고, 해당 VO의 값에 대한 벨리데이션 검증 로직을 VO로 빼는 경우도 많게 된다. 예를 들면Value Class Email(value:String) { init { //value 검증 로직. (Email포멧 검증..
[개발생각] 동일한 역할의 API 인터페이스를 도메인에서 분리해야할때
다른 방식으로 동작하는 동일한 역할을 하는 API는 깔끔하게 도메인 레이어에서 제거하는게 더 깔끔해진다. 도메인 주도 설계 개발을 하게 되면, 아래와 같은 상황이 올때가 있다. 예를 들면, ci를 넘기면, 그 ci의 주민등록상의 주소를 리턴해주는 API를 연동한다고 해보자.그런데, 해당 API는 불안해서, 또는 다른 이유로 같은 기능을 제공하는 몇개의 다른 API를 보조로 사용하려고 한다.(A api 죽으면, B api 사용,)그런데 각각의 A, B API는 응답을 주는 방식이 틀리고, 요청파라미터도 다르다.하나는 요청하면 바로 응답값을 주는 동기방식이고, 하나는 요청하면, 콜백URL을 통해 나중에 전달해주는 콜백 비동기 방식이다. 이런경우, 도메인 서비스에서 비즈니스 로직을 구현할때,해당 api호출을 ..
[개발생각] '개발 문화'라는 달콤한 열매
'개발 문화'라는건 지층이나 퇴적물과 생성과정이 사뭇 비슷하지 않을까? 생각한다. 오랜세월 차곡차곡 퇴적물이 쌓이고, 비,바람,압력등으로 견고하게 한층한층이 단단해지듯이, 꽤 오랜 세월이 필요하고,오랜 노력과 역경이 필요한 것! 이 결과물이 '개발문화'라고 생각한다. 결국, 우당탕탕 싸우고, 의견을 나누고, 협의하고, 공감하고 등의 역경/시련이 반드시 필요하다는것이다.그중, 가장 중요한것은 다수의 공감, 그리고 그에 따른 다수의 노력/실행이다. 공감은 개발자의 모두가 해당 문화에 대해 공감을 이뤄야하는 시간과 실질적으로 공감을 하는 자리가 마련되어야 한다는 필요 충분조건이 필요하며, 지속적이고, 집요하리만큼...꾸준함으로 술이 익기를 기다리는것과 같이, \그 여유를 견디고 즐기며,기다릴줄 알아야 하는 시..
