도메인 모듈을 패키지로 변환하기

기존 코드를 모듈화하기 위한 일반적인 단계는 다음과 같을 수 있습니다:

1. 동일한 네임스페이스를 사용하여 해당하는 bounded context와 관련된 모든 클래스 및 모듈에 대해 사용합니다.

   • 왜? 코드베이스에서 사용 중인 도메인을 대략적으로 파악하지 않고는 계획을 세우기 어렵습니다. 모든 다른 사람이 따를 수 있는 잘 네임스페이스가 지어진 코드는 모듈화의 전제 조건이기도 합니다.
   • 도메인이 이미 잘 네임스페이스가 지어져 있고 유사한 네임스페이스가 없다면, 다음 단계로 직접 이동할 수 있습니다.

2. Rails 개발을 Packwerk 패키지에 대비합니다. 이것은 일회성 단계이며 시간이 지남에 따라 일부 개선이 있을 수 있습니다.

   • 우리는 Rails 자동로더를 Packwerk의 디렉터리 구조와 함께 동작하게 할 것이며, 이 PoC에서 보여졌습니다.
   • 우리는 Merge Request에 대해 CI에서 Danger-Packwerk를 실행할 것입니다.
   • 아마도 Packer 체크를 pre-commit 또는 pre-push에서 Lefthook에서 실행할 것입니다.

3. 파일을 Packwerk 패키지로 이동합니다.

   • 이는 Packwerk 패키지를 만들고 파일을 반복적으로 패키지로 이동하는 과정으로 구성되어야 합니다.
   • 상수들은 Packwerk 패키지 내의 app/ 또는 lib/에 있더라도 올바르게 자동로드됩니다.
   • 이는 도메인 코드가 패키지 디렉터리와 Rails 디렉터리 구조 간에 분할될 단계입니다. 우리는 여기서 빠르게 움직여야 합니다.

4. 패키지가 다른 패키지의 public interface를 사용하도록 의존성을 명시적으로 선언하도록 하여 네임스페이스 경계를 강화합니다.

   • 왜? 지금까지 우리는 모든 상수가 공개 상태였으므로 우리가 개인 정보를 강제하지 않았습니다. 경계를 강화하지 않은 채 기존 파일을 패키지로 이동함으로써, 우리는 패키지 프라이버시 위배에 촛점을 맞출 필요 없이 패키지 내의 네임스페이스를 래핑하는 데 집중할 수 있습니다. 이후에 프라이버시를 강제함으로써, 우리는 다양한 상수와 도메인 간의 결합에 대한 이해를 얻을 수 있습니다.
   • 이렇게 함으로써 우리는 다른 패키지에서 사용되는 상수를 공개해야 하는지(다른 패키지에서 사용되기 때문에)와 캡슐화의 이점을 살릴 수 있는지(비공개로 유지할 수 있는지)를 알게 됩니다. 우리는 Packwerk의 기록된 위반사항(RuboCop TODO와 유사함)을 통해 시간이 흐름에 따라 코드를 리팩터링할 것입니다.
   • 우리는 의존성 그래프를 업데이트하여 전체 아키텍처에 맞게 어디에 들어가는지를 볼 수 있습니다.

5. Packwerk의 기록된 위반사항을 바탕으로 리팩터링합니다. 이는 도메인의 DRIs(Directly Responsible Individual)가 시간을 들여 돌보아야 하는 장기적인 단계입니다. 우리는 Packwerk의 실패 및 의존성 다이어그램을 활용하여 모듈화된 디자인에 영향을 줄 것입니다.

   • 클래스가 퍼블릭이 아닌 개인이어야 하는지 재검토하고, 더 나은 인터페이스를 생성합니다.
   • 그것과 너무 결합된 경우 다른 패키지로 상수를 이동합니다.
   • 서로 너무 결합되어 있는 패키지를 결합합니다.

Rails 애플리케이션에 Packwerk를 구성한 후(위의 단계 2), 신흥 도메인은 격리되고 명확한 인터페이스를 즉시 활용할 수 있는 Packwerk 패키지로 직접 구현될 수 있습니다.