프로젝트 모듈 관리 팁

주말 용, 소소한 팁입니다.

도메인 로직을 구현하기 위해, 저는 보통 콘솔앱으로 시작합니다. (다들 그러시겠지만)
코드 작성하고 실행해보고, 오류 찾고… 뭐 그런 일의 반복이죠.

저만의 루틴이라며, 이 프로젝트에 Sandbox 접미사를 붙이는 것입니다.

MyProject.Sandbox

코드 작성 => 실행의 반복으로 도메인 로직을 만들어 나가다 보면, 도메인에 속하는 객체가 자연히 드러나는데, 이들은 Domain 폴더에 넣어 관리합니다.

  • MyProject.Sandbox
    • Domain

때로는 확장메서드를 위한 객체들이 생성되는데, 이들은 Common 폴더에 넣어 관리합니다.

  • MyProject.Sandbox
    • Domain
    • Common

물론, 샌드박스는 테스트 코드도 포함할 수 있습니다.

  • MyProject.Sandbox
    • Domain
    • Common
    • Test
      • Domain
      • Common

샌드박스에서 특정 기능의 구현이 어느 정도 완성되면, 각 폴더에 있는 객체들은 클래스 라이브러리 프로젝트로 옮깁니다.

  • MyProject.Domain
  • MyProject.Common
  • MyProject.Test

물론 이 프로젝트들에 대한 참조를 샌드박스에 추가합니다.

문제는, 파일들을 다른 프로젝트에 옮길 때 네임스페이스 정리하느라 난리 부르스가 난다는 것이죠.

이쯤이면 눈치 채셨겠지만, 이 문제는 MyProject.Sandbox 생성 시에, .csproj 에 아래와 같이 루트 네임스페이스를 설정해주면 쉽게 해결이 가능합니다. (다른 프로젝트는 이러한 설정을 하지 않습니다)

  <PropertyGroup>
    ...
    <RootNamespace>MyProject</RootNamespace>
  </PropertyGroup>

이 설정으로 인해, MyProject.Sandbox.Domain 폴더에 생성되는 모든 객체들은 아래의 네임스페이스를 갖게 됩니다.

namespace MyProject.Domain; 

이 네임스페이스는 MyProject.Domain 프로젝트의 루트 네임스페이스와 같습니다.

파일들이 다른 프로젝트로 옮겨지기 전이나 후나 동일한 네임스페이스를 유지하게 됩니다.
네임스페이스 유지의 효과는 꽤 실용적입니다.

완성된 로직을 모듈화하고 나서도, 네임스페이스 충돌이 없기 때문에, 샌드박스는 언제나 "신규로 구현 중인 로직"만을 위한 객체로 간결하게 유지할 수 있습니다.

마지막으로, 루트 네임스페이스를 상수로 설정하면, 이름 변경 시 적용이 안되기 때문에, 실제로는 아래와 같이 씁니다.

  <PropertyGroup>
    ...
     <RootNamespace>$( MSBuildProjectName.Replace(" ", "_").Substring(0, $(MSBuildProjectName.IndexOf('.'))))</RootNamespace>
 </PropertyGroup>
9 Likes

개인적으로 git 이용한 feature 전략을 쓰는것도 괜찮지 않을까 싶습니다

feature/task1 → 통과

QA 브랜치 머지 → 통과
Staging 브랜치 머지 → 통과
Live 반영 이런식으로요

2 Likes