IdaPrototype

대구소프트웨어마이스터고등학교 차세대 입학 전형 시스템 샘플 프로젝트

목차

Ⅰ. IdaPrototype이란?
Ⅱ. 설계
 ⅰ. 레이어 모듈별 규칙
 ⅱ. 공통 모듈
  1. 예외 핸들링
Ⅲ. 프로세스 규칙
 ⅰ. github 프로젝트 규칙
 ⅱ. 이슈 명명 규칙
 ⅲ. 브랜치 명명 규칙
 ⅳ. 병합 규칙

IdaPrototype이란?

IdaPrototype 프로젝트는 DDD와 Hexagonal을 결합하여 지속 가능한 소프트웨어 설계를 지향하는 프로토타입형 프로젝트입니다. DDD와 Hexagonal을 연습하고 차후 실제 운영까지는 아니더라도 좋은 샘플로서 남겨지도록 하는 것이 목표입니다.

설계

IdaPrototype은 앞서 서술하였듯이 DDD와 Hexagonal을 결합한 프로토타입형 프로젝트입니다. 보다 편리한 프로젝트 관리를 위하여 멀티-모듈로 분리하여 각각의 레이어를 표현합니다. 레이어 및 모듈 규칙은 다음과 같습니다.

• Application 레이어 모듈은 하나만 존재한다.
  • 이때 명칭은 "http-application"이라 명명한다.
• 각각의 애그리거트로 도메인과 인프라-스트럭쳐 레이어를 구현한다.
  • 애그리거트 하나당 도메인, 인프라-스트럭쳐 레이어를 하나씩만 구현할 수 있도록 제한한다.
• 애그리거트 도메인과 인프라-스트러쳐 레이어는 다음과 같은 명명 규칙을 따른다.
  • 도메인 레이어는 "{애그리거트명}-domain"이라 명명한다.
  • 인프라-스트럭쳐 레이어는 "{애그리거트명}-infrastructure"이라 명명한다.
  • 예를 들어 회원 애그리거트를 구현해야할 때에는 다음과 같이 명명한다.
    • ex) 도메인 레이어는 "member-domain"
    • ex) 인프라-스트럭쳐 레이어는 "member-infrastructure"

레이어 모듈별 규칙

각각의 레이어는 책임이 각각 나뉘어져 있습니다.

• 애플리케이션 레이어는 실제 사용자와 접촉하는, 사용자가 직접적으로 접근하는 레이어이다.
  • 보통 컨트롤러를 구현하고, 컨트롤러단(MVC 모델에서의 Controller)에서 발생하는 예외를 핸들링한다..
• 도메인 레이어는 애플리케이션 레이어와 인프라-스트럭쳐 레이어를 서로 연결하고 특정 로직을 해소하는 레이어이다.
  • 보통 도메인 클래스를 구현하고, 인프라-스트럭쳐 API를 정의(definition)한다.
  • 정의된 API를 통해 응용 서비스(use-case)를 구현한다.
  • 인터페이스의 필요성이 느껴지지 않는 다면 응용 서비스를 인터페이스로 정의(definition)하지 않는다.
  • 여러 애그리거트가 필요한 로직 혹은 복잡한 계산 로직이 요구된다면 도메인 서비스를 별도로 만들어 위임한다.
    • 특정 기능이 응용 서비스인지 도메인 서비스인지 헷갈린다면, 해당 로직이 애그리거트의 상태를 변경하거나 애그리거트의 상태값을 계산한다면 도메인 서비스로 분리하도록 한다.
• 인프라-스트럭쳐 레이어는 저수준 모듈로, 외부 리소스(외부 라이브러리 등)을 통해 도메인 레이어의 API를 구현하여 구현체를 구현한다.
  • 응용 서비스에서 구현하기에는 다소 어렵거나 복잡한 경우에는 이 레이어에 위임하여 처리하는 것 역시 가능하다.
  • 외부 리소스 빈 생성 등 설정들 역시 이 레이어에서 처리한다.

모듈마다 각각 README.MD를 반드시 작성하시길 바랍니다.

공통 모듈

공통적으로 가져야하는 클래스 혹은 인터페이스들은 따로 모듈로 분리하여 관리합니다. 명명규칙은 "common" 혹은 "ida-common"이라고 명명합니다.

예외 핸들링

예외 최상위 클래스(추상 클래스 포함) 공통 모듈 안에 존재해야하며, 다음과 같이 관리합니다.

• 도메인 레이어의 최상위 예외 클래스는 추상 클래스로 RuntimeException을 상속합니다.
• 도메인 레이어에서 발생되는 하위 예외 클래스들 역시 공통 모듈에서 각각 HTTP 4xx의 모습을 지닌 예외 클래스로 작성합니다.
• 도메인 레이어에서 발생되지 않는 경우에는 공통 모듈이 아닌 각각의 인프라-스트럭쳐에서 따로 관리합니다.

프로세스 규칙

2~4주마다 담당한 브랜치를 전속력으로 개발하여 병합(merge)하는 것을 목표로 합니다. 전체적인 프로세스는 github 프로젝트 작성 -> 담당 이슈 생성 -> 브랜치 생성 -> 구현 -> 코드리뷰 -> 병합 순으로 이루어집니다.

github 프로젝트 규칙

하나의 프로젝트에서 진행하는 것이 아닌 각각의 애그리거트의 프로젝트를 작성하여 독립적으로 작성합니다. 그전에 진행해야하는 작업이 요구되는 경우, 먼저 동시에 작업을 진행한 후, 틀이 잡아졌다면 진행합니다.

이슈 명명 규칙

이슈는 github 프로젝트를 통해 이슈를 생성합니다. 이때, 진행해야하는 업무를 작성합니다. 명명규칙은 다음을 따릅니다. ※ topic은 "무엇"을 중점적으로 할 것인지에 대해 작성하면 됩니다.

• 일반 설정의 경우 - config-(topic)
  • ex) config-initialize
• 기능 구현의 경우 - feature-(topic)
  • ex) feature-school-domain
• 리팩토링의 경우 - refactor-(topic)
  • ex) refactor-score-calculate
• 핫픽스의 경우 - hotfix-(topic)
  • ex) hotfix-attendance-score
• 요구사항 변동의 경우 - change-(topic)
  • ex) change-volunteer

브랜치 명명 규칙

이슈 생성을 통해 생성된 이슈 넘버를 통해 참조하도록 합니다.

• config-#(n)
• feature-#(n)
• refactor-#(n)
• hotfix-#(n)
• change-#(n)
• merge-#(n)
  • merge 브랜치는 레이어 검수를 위해 필요한 브랜치입니다.

병합 규칙

config, hotfix 브랜치는 merge commit으로 진행합니다. feature, change, refactor, merge 브랜치는 squash & merge로 진행합니다. 단, change의 경우 기록이 남아있어야 하다고 판단된다면 merge commit을 허용합니다.