건축 (구조) 중심 대 기능 중심 프로젝트 구조


14

내가 참여한 프로젝트는 아키텍처 지향 프로젝트의 파일 / 폴더 구조를 가지고 있습니다.

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

시스템의 구조적 관점에서 분명하다 (개발팀이 제안한).

디자이너 팀이 제안한 기능 지향 구조입니다.

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

이 변형은 설계자에게 더 가까우며 구현할 기능을 명확하게 설명합니다.

우리 팀은 성전을 시작했습니다. 가장 좋은 방법은 무엇입니까? 누군가 우리를 도와 첫 번째와 두 번째의 단점과 장점을 설명 할 수 있습니까? 어쩌면 우리 둘 다에게 더 유용하고 유익한 세 번째 것이있을 것입니다.

감사합니다.


어느 구조도 이해하지 못합니다-이벤트와 요청 (및 이벤트 처리기와 요청 처리기)의 차이점은 무엇입니까?
— 피터 Boughton

1
매우 명확한 질문-그리고 중립!
— Michael K

1
확장 성 관점에서 두 번째 접근 방식은 수평 확장이 상당히 쉬워야합니다.
— CodeART

답변:


11

두 번째 투표에 투표하겠습니다. 첫 번째 구조에서의 이벤트 핸들러는의 이벤트 핸들러와 FeatureA완전히 관련이 없습니다 FeatureB. 개발자가 한 번에 하나의 기능을 작업하는 것으로 보이며 요청을 처리 FeatureX하는 FeatureX경우 요청보다 요청 핸들러 를 조정해야 할 가능성이 훨씬 높습니다 FeatureZ.

그건 그렇고, 당신이 중립적 관점 에서이 질문을 한 방법을 좋아합니다.


1
하나의 경고와 함께 +1 : 작은 프로젝트의 경우 두 번째는 파일을 넣을 파일보다 파일 구조가 더 큽니다. 그 중 첫 번째 파일을 사용하겠습니다.
— Michael K

@ Michael 나는 동의하지만,이 경우에는 큰 프로젝트입니다.
— Zzz

1
+1 : 사용자 / 클라이언트와 대화해야하는 경우 용어가 상당히 일관 될 수 있습니다.
— Steven Evers

4

저는 항상 두 번째 접근 방식에 더 편했지만, 항상 공유 / 기본 수업에 일반적 또는 공통이라고하는 "기능"을 가지고 있습니다.

두 가지 접근 방식은 진정으로 분리 된 사물을 유지하지만 "공통"영역이없는 경우에는 종종 사물을 적합하지 않은 영역으로 분리합니다.


일반 및 일반 +1 (모든 프로젝트에는 일반 유틸리티, 도구가 있습니다 ...)
— Zzz

3

기능 발명자가 구현 세부 사항에 관심을 갖는 이유는 무엇입니까? 그것이 논쟁의 측면들 사이의 분리라면, 나는 그 대답이 분명하다고 생각합니다. 아이디어 / 기능을 발명하는 사람들은 구현자가 필요로하는 파일 구조를 결정하지 않습니다.

기능의 구현이 여러 dll, exe, 데이터베이스 또는 기타 소프트웨어에 걸쳐있을 때 특히 중요한 문제입니다.


1
나는 그것에 대해 생각했지만 다른 모든 것들은 동일하지만 두 번째 접근법은 가장 사소한 응용을 제외하고는 모든 사람들에게 명확한 철학적 이점을 가지고 있습니다. 최소한 좋은 제안입니다.
— Robert Harvey

@Robert Harvey : 프로젝트의 아이디어 구성에 대해 이야기하고 있다면 새로운 답을 생각 해봐야합니다. 그러나 코드가 포함 된 파일에 대해 말하는 것처럼 들립니다.
— John Fisher

핵심은 기능을 개별 버킷으로 분리하는 것입니다. 가장 작은 응용 프로그램을 제외한 모든 응용 프로그램의 경우 폴더 구조, 클래스 구조 또는 네임 스페이스 규칙을 참조 할 때 이와 같은 조직이 필요합니다.
— Robert Harvey

1
@Robert Harvey : 빌드 및 배포 문제는 어떻습니까? IDE를 사용하여 코드를 작성하고 디버깅하는 것과 같은 간단한 작업은 어떻습니까? 이 중 일부는 폴더 구조에 큰 영향을 미칩니다.
— John Fisher

1

두 가지 옵션을 고려할 때 두 번째 접근 방식에 동의해야합니다. 첫 번째는 비정질 얼룩처럼 보입니다. 적어도 두 번째는 어떤 모양을 가지고 있습니다.

그것은 실제로 프로젝트의 규모에 달려 있습니다. "기능"이 큰 경우 각각 고유 한 버킷이 필요합니다.


1

나는 당신이 사용하는 용어를 이해하지 못하지만 어쨌든 두 구조가 모두 잘못된 접근법 인 것처럼 보이기 때문에 대답하려고 시도합니다.

소수의 기능 만 가지고 있지 않는 한, 기능을 범주로 그룹화해야합니다. 이는 Node1이 의도 한 것이 아니라면 "프로젝트의 모든 X"가 제안하지 않는 한 어느 디자인에도 적용되지 않는 것으로 보입니다. 그렇지 않으면 WTF가 궁금합니다. Node2가 있습니까?)

다음과 같은 것을 고려할 수 있습니다.

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

아니면 이거:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events


그러나 그들은 모두 완전히 벗어난 가정을하고 있습니다. 자세한 내용으로 질문을 업데이트 할 수 있다면 마음이 바뀔 수 있습니다. :)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.