[Spring Framework] 비즈니스 로직 층의 패턴

 

비즈니스 로직 층을 설계할 때는 어느 클래스에 로직을 할당할지 중요하다. 판단하기 아주 어려운 문제지만 설계 실력을 보여줄 수 있는 기회이기도 하다. 여기서 실패하면 아픙로의 작업이 힘들어지므로 실제 개발에서는 서둘지 말고 차분히 생각해서 결정해야 한다.

 

 

 

출처 : https://javacan.tistory.com/entry/94

트랜잭션 스크립트

일반적인 지침으로는 데이터베이스의 내용을 표시/변경하기만 하는 업무 처리, 즉 비즈니스 로직이 적은 단순 입출력 애플리케이션일 때는 로직을 전부 서비스 클래스에 포함시키는 편이 좋다. 또한, 객체 지향 지식이 없는 프로그래머가 많이 일하는 대규모 개발 프로젝트에서도 도메인에는 가능한 한 로직을 포함시키지 않는 편이 좋을 것이다. 이때는 도메인이 아니라 단순히 값을 저장하기만 하는 오브젝트, 사람에 따라서는 VO{(Value Object), (값을 저장하는 오브젝트)}나 DTO{(Data Transfer Obejct), (값을 전달하기만 하는 오브젝트)}라고 부르는 것이 된다. 이렇게 쓰면 로직이 없는 도메인 클래스는 객체 지향이 아니라고 비판하는 사람도 있지만 신경 쓸 필요는 없다. 비판은 학자들에게 맡기고 우리는 프로젝트를 성공시키는 가장 좋은 방법을 생각해야 한다.

그러나 언제까지나 객체 지향을 잘 모른다고 한다면 엔지니어로서 자질을 의심받을 것이다. 최근에는 에릭 에반스가 제안한 도메인 주도 설계도 주목받고 있다. 대규모 개발이라도 중요한 도메인이면 다음에 설명할 도메인 모델로 웹 애플리케이션을 만들어보는 것이 좋다.