MyungHoon_Ju
by layer
다음은 흔하게 볼 수 있는 데이터기반의 구조이다
다음과 같은 상황은 우리가 유지보수를 하는데 어려움을 주는 요소 중에 일부이다
이러한 구조는 우리가 어플리케이션을 만들때 가장 먼저 데이터 구조를 먼저 설계하기 때문이다
ORM 프레임워크의 사용 또한 비즈니스 로직과 영속성을 위한 로직이 뒤섞이게 되는 요인이다
예를들어 지연로딩여부, 트랜잭션의 사용, 영속성 관리 등이 이에 해당한다
층 구조는 구현함에 있어 정의된 규칙은 없다 그래서 아래처럼 구현하는 것도 가능하다
example 1
특정 컴포넌트가 별도로 필요한 경우 helper, util 처럼 생성해서 영속성 계층에 넣고 사용할 수도 있다
어떠한 요소든 어디에나 만들어서 사용할 수도 있다
example 2
복잡한 비즈니스 로직이 없고 간단한 CRUD 필요하다면 도메인 계층을 건너뛰고 바로 영속성 계층에 접근한다
- 향후 비즈니스 로직이 복잡해질 수록 모든 계층에 비즈니스 로직이 산재되어 존재한다
- 단위 테스트 하는 경우 하나의 층만 테스트 하는데 어려움이 있다
example 3
층 구조는 도메인 서비스의 넓이/범위를 규정하지 않아, 하나의 서비스에 다수의 시나리오를(use case) 구현할 수 있다
특정 시나리오를 수정하는 경우 해당하는 부분이 명확하게 드러나지 않는다
위와 같은 구조에서 여러명이 동시에 유지보수 및 개발을 진행한다면?
1. 계층마다 순서대로 진행해야 일을 할 수 있거나(동시개발에 어려움)
2. 동일한 서비스를 다양한 이유로 여러명이 수정을 해야함으로 병합충돌 및 변경사항을 유실할 수 있다