디렉토리(패키지) 구조 - 계층보다는 기능에 의한 분류

http://www.javapractices.com/topic/TopicAction.do?Id=205

위 링크의 글을 번역하여 나름대로 정리한 글입니다. 

위 글은 자바의 package 를 어떤 기준으로 나눌지에 대한 글입니다.

 

되게 당연해보이고 이미 아는 것 같은 내용이지만,
생각보다 당연하게 뇌피셜 기준으로 디렉토리를 막 만드는 나를 발견합니다.

 

프로젝트 디렉토리 구조를 세울 때마다 제발 이 글 좀 보고 각성하라고 미래의 나에게 이 글을 바칩니다.

---

응용 프로그램을 빌드할 때 첫 번째 질문은 "어떻게 패키지로 나눌 수 있습니까?"입니다.

일반적인 비즈니스 애플리케이션의 경우 이 질문에 답하는 두 가지 방법이 있는 것 같습니다.

기능별 패키지

단일 기능과 관련된 모든 항목을 단일 디렉토리에 배치합니다.

그 결과 결합을 최소화하여 높은 응집력과 높은 모듈성을 가질 수 있습니다.

그러면 밀접하게 동작하는 항목들은 응용 프로그램 전체에 퍼져 있지 않고, 가까이에 배치됩니다.

어떤 경우에는 디렉토리만 삭제하여 기능을 삭제할 수 있습니다. (삭제 작업은 최대 모듈성을 위한 좋은 테스트로 생각할 수 있습니다. 항목은 단일 작업으로 삭제할 수 있는 경우에만 최대 모듈성을 갖습니다.)

패키지 이름은 중요한 상위 수준의 문제 영역에 해당합니다.

예를 들어, 약물 처방 응용 프로그램에는 다음과 같은 패키지가 있을 수 있습니다.

• doctor
• drug
• patient
• presription
• report
• security
• webmaster
• util
• and so on...

각 패키지는 일반적으로 특정 기능과 관련된 항목만 포함하고 다른 기능은 포함하지 않습니다.

패키지에는 해당 기능이 작동하는 데에 필요한 모든 항목이 있습니다. 인터페이스, 상수, js 코드 등 주어진 기능과 관련된 모든 항목이 해당 기능 전용 단일 디렉토리에 있어야 합니다.

기능별 패키지 아이디어는 한 패키지가 다른 패키지에 속한 항목을 절대 사용할 수 없다는 것을 의미하지 않습니다.

오히려 기능별 패키지는 기본 범위로는 단일 패키지를 적극적으로 선호하고, 필요할 때만 항목의 범위를 공용으로 늘립니다.

이렇게 특정 기능/패키지가 응용 프로그램의 다른 기능에서 사용되는 경우, 제거는 단일 삭제 작업만큼 간단하지 않습니다.

레이어별 패키지

최상위 패키지는 다음과 같이 기능 대신 다양한 애플리케이션 "계층"을 반영합니다.

• action
• model
• util

각 디렉토리에는 일반적으로 서로 밀접하게 관련되지 않은 항목이 포함되어 있습니다.

그 결과 패키지 간의 결합이 높아, 응집력이 낮고 모듈성이 낮은 패키지가 생성됩니다.

결과적으로 기능을 편집하려면 여러 디렉터리에 있는 파일을 편집해야 합니다.

또한 한 번의 작업으로 기능을 삭제하는 것은 거의 불가능합니다.

권장: 기능별 패키지 사용

더 높은 모듈성

위에서 언급한 바와 같이 기능별 패키지는 응집도가 높고 모듈성이 높으며 결합도가 낮습니다.

더 쉬운 코드 탐색

주어진 작업에 필요한 모든 항목이 일반적으로 동일한 디렉토리에 있기 때문에, 유지 관리 시 항목 검색을 훨씬 덜 수행할 수 있습니다.

레이어별 패키지는 패키지 명명 규칙을 사용하여 지루한 코드 탐색 문제를 완화합니다.

그러나 기능별 패키지는 디렉토리 간 탐색의 필요성을 크게 줄임으로써 애초에 그러한 규칙의 필요성을 초월합니다.

더 높은 수준의 추상화

높은 수준의 추상화를 유지하는 것은 프로그래밍의 원칙 중 하나입니다. 문제에 대해 생각하기 쉽게 만들고, 구현 세부 사항보다 기본 서비스를 강조합니다.

높은 수준의 추상화에 대한 직접적인 이점으로는 그 자체가 응용 프로그램의 문서가 된다는 점입니다.

응용 프로그램의 전체 크기는 패키지 수로 전달되고 기본 기능은 패키지 이름으로 전달됩니다.

반면에 레이어별 패키지 스타일의 근본적인 결함은 구현 세부 사항이 높은 수준의 추상화보다 앞선다는 것입니다. 이는 거꾸로입니다.

기능과 레이어를 분리

기능별 패키지 스타일은 여전히 레이어를 분리하는 아이디어를 존중하지만, 해당 분리는 별도의 클래스를 사용하여 구현됩니다. → 디렉토리는 기능별 분리, 말단의 파일들은 계층으로 분리

반면에 레이어별 패키지 스타일은 별도의 클래스와 별도의 패키지를 모두 사용하여 분리를 구현하므로 바람직하지 않습니다. → 디렉토리, 말단의 파일 모두 계층으로 분리

범위 최소화

범위를 최소화하는 것은 지속적인 가치의 또 다른 지침입니다. 기능별 패키지 스타일을 사용하면 일부 클래스가 공개에서 비공개로 범위를 줄일 수 있습니다. 이는 중요한 변경 사항이며 파급 효과를 최소화하는 데 도움이 됩니다.

반면에 레이어별 패키지 스타일은 패키지 비공개 범위를 효과적으로 포기하고 거의 모든 항목을 공개로 구현하도록 강요합니다. 이것은 비밀을 유지하여 파급 효과를 최소화할 수 없기 때문에 근본적인 결함입니다.

더 나은 성장 스타일

기능별 패키지 스타일에서 각 패키지 내의 클래스 수는 특정 기능과 관련된 항목으로 제한됩니다.

패키지가 너무 커지면 자연스럽게 두 개 이상의 패키지로 리팩토링될 수 있습니다.

반면에 레이어별 패키지 스타일은 모놀리식입니다. 애플리케이션의 크기가 커짐에 따라 패키지 수는 거의 동일하게 유지되는 반면 각 패키지의 클래스 수는 제한 없이 증가합니다.