이전 프로젝트 회고

도메인 주도 개발의 도입을 목적으로 한단계씩 밟아갔던 리팩토링 과정에 대해 적어본다해당 글은 회고목적으로 작성된 글이며, 코드내용은 포함하고 있지 않습니다. 이 글에서는 상품판매구성 - 상품판매구성값을 리팩토링 한 과정에 적어보겠다.image자세히는 적을 수 없지만 위

DTO와 모델 구분에 관해 다시한번 생각해본다. 해당 프로젝트가 정확히 3개 영역으로 나눈것은 아니고, 3개의 영역으로 나누는게 정답이라는것도 아니지만, 설명을 위해 3개 영역으로 나눈것으로 하겠다.모든 코드의 구조가 아래와 같지는 않았지만, 상당히 많은 곳에서 아래와

이전 글에서 예고한데로, 서비스클래스를 리팩토링하며 테스트코드, 디자인패턴에 관한 내 생각을 정리해보았다.왜 나는 테스트하기 어려운 코드를 리팩토링 대상으로 선택했을까? 프로젝트에서 테스트코드의 본질은 뭘까? 가장 쉽게 떠오르는 답변은 작성한 코드가 올바르게 수행하는지

객체들의 관계를 RDB로 나타낼때 사용된다. @JoinColumn 은 RDB의 외래키컬럼 된다. 객체는 메모리주소를 저장하는 방식으로 연결을 처리한다. RDB는 다른 테이블의 키 값을 저장해 연결을 처리한다. 1:N 관계에서 객체는 컬렉션이라는 개념으로 1:N을 처리한

얼마전 인프런에서 김영한님의 hibernate 강의를 복습하는 중, 양방향 관계일경우 연관관계 편의 메소드라는 것을 사용하는것을 보았다. 사용해야 하는 이유는 강의 내용에 있었지만(위의 적어놓은 내용과 크게 다르지 않았다) JPA 레퍼런스, hibernate 에서는 어

시작하며DTO, Command Object, Value Object (이하 VO)에 대해 적어보려 한다. 특히 DTO와 VO 가 구분없이 불리게된 이유를 찾아봤다DTO 라는 개념 자체가 긴 시간을 거쳐, 여러 환경에서 사용하다보니 그 과정을 정리해둔 페이지는 아직 보지

프로젝트를 시작하면 초반에 한번씩 고민하고 넘어가는 것들이 있다. DTO, VO 와 마찬가지로 DAO, Repository, DataMapper 가 그 중 하나인데, 이번 기회에 정리해보려 한다. 현재는 사실상 일반화 되서 사용되는 ‘데이터를 가져오는 객체’ 라는 뜻도

결론은 도메인주도개발에서는 ORM(hibernate-framework)를 적용하는 것이 효율적이다. Hibernate-framework를 적용하지 않으면 DB를 처리하는 부분에서 직접 작성한코드가 들어간다. 문제는 이 코드가 굉장히 많아진다는 것이다.조회기능은 Myba