기본 사항

프로젝트를 진행하는 데 있어 기본적인 아키텍쳐와 몇 가지 정해진 사항들이 있다

• 전체적인 애플리케이션 아키텍처는 Layered Architecture 를 따른다
• 객체의 설계는 객체지향적으로 설계한다
• 최초에는 DB 를 사용하지 않는다
• 기술의 사용은 명확한 이유가 존재해야 한다

패키지 구조

Layered Architecture 를 따르는 패키지 구조는 회사마다 다르게 정해진다

하지만 기본적으로 해당 프로젝트는 객체지향적으로 설계되는 것을 목적으로 만들어진다

그렇다면 객체끼리의 협력과 웹에 의존적인 설계를 하지 않는다고 생각하며 패키지 구조를 고민해보자

객체지향적인 패키지 구조.
그렇다면 web 에 너무 치우치지 않은, 확장하기 용이한 형태의 패키지 구조가 나을 것이다. 외부에 대한 의존성은 한 곳으로 몰고, 프레임워크에 대한 의존도 빼버린다는 가정을 하면 root 패키지 구조는 아래와 같이 나올 수 있다

root
|- application
|- domain
|- presentation
|- persistence

• application
  해당 애플리케이션에서 설정에 필요한 요소나 Util 에 대한 코드를 몰아넣을 용도의 패키지 분류이다. 단, Util 은 반드시 도메인 코드가 들어가선 안된다.
  외부 의존성을 허용하나, domain 과 application 패키지의 하위 요소에 대한 의존은 존재해서는 안된다.
• domain
  POJO 를 작성하는 공간이다.
  해당 영역은 외부 의존성에 대해 완전한 보호 조치가 이루어져야 한다. 라이브러리를 포함하여 어떠한 의존성도 가져서는 안되며 외부 의존성이 존재하는 코드가 들어와서도 안된다. 여기서 말하는 외부 의존성은 domain 패키지 내에서 만들어진 것이 아닌, 상위 패키지나 동위 패키지, 동위 패키지의 하위 패키지의 의존성도 포함된다.
• presentation
  Web 에 의존적인 코드가 모이는 공간이다
  Web 과 관련된 코드를 작성하며 주로 Controller 나 DTO 가 위치할 수 있다.
  application 과 domain 에 의존하며 외부 의존성을 허용한다.
• persistence
  데이터를 어떻게 저장하고 사용할 것인지에 대한 패키지 이다.
  물론 데이터베이스에 저장한다는 행위 자체가 해당 '도메인' 과 직접적인 연관성이 있다고 생각하지만 '비즈니스' 는 아니라고 가정하고 진행한다. 이유는 도메인이 저장되는 로직을 알 필요가 없다고 생각되기 때문이다. '저장' 은 도메인 관심 요소라기 보다는 애플리케이션의 관심 요소이며 그렇다고 application 이라기엔 너무 포괄적이기 때문이다.

각 상위 패키지에 대한 하위 패키지를 4 Tier Layered Architecture 를 기준으로 설계해보자

Layered Architecture 에서 현재 고민 할 부분은 몇 티어를 사용 할 것인가 이다

현재 모델은 4 Tier 이지만 사실 도메인에 대한 코드를 작성하고 구현하다보면 도메인간의 연결과 파사드를 위해 도메인 - 서비스 사이에 계층이 하나 더 존재해야 할 수 있다고 생각한다

그렇다면 4 Tier 가 맞을까, 라는 질문에는 사실 Service 를 파사드 개념으로 활용하고 내부 비즈니스를 도메인으로 몰아버리면 도메인 - 서비스, 퍼시스턴스 - 프레젠트 로 4티어가 완성된다.

티어에 대한 고민은 내일 진행해보자

오늘의 고민은 마침.