예를 들어 MVC와 같은 아키텍처를 사용하는 경우 어떤 폴더 구조를 사용해야합니까?
domain1/
controller
model
view
domain2/
controller
model
view
또는:
controllers/
domain1
domain2
models/
domain1
domain2
views/
domain1
domain2
이 질문을 언어에 구애받지 않기 위해 의도적으로 파일 확장자를 생략했습니다.
개인적으로 비즈니스 영역 (장감)으로 분리하는 것을 선호하지만 대부분 / 많은 프레임 워크가 기술 영역별로 분리되어 있음을 알 수 있습니다. 왜 내가 다른 하나를 선택해야합니까?
답변
나는 이것이 특정 프로젝트에 달려 있다고 생각합니다.
예를 들어 서로 다른 비즈니스 도메인이 서로 완전히 독립적 인 경우 비즈니스 도메인별로 구성합니다.
그러나 비즈니스 도메인간에 공유 코드가 있거나 비즈니스 도메인이 동일한 코드 기반의 다른 변형 인 경우 기술 도메인별로 구성하는 것이 더 논리적으로 보입니다. 그리고 어떤 종류의 객체 지향 언어를 사용한다면, 비즈니스 특정 파일에서 일반 컨트롤러, 모델 등을 서브 클래스 화하여 더 얇게 만들 수 있습니다.
또한 두 개의 스트립 아웃 공유 코드를 자체 도메인에 넣고 다른 도메인에서 사용하는 중간에 중간에 있습니다. 이를 통해 직감에 기반한 레이아웃을 제공하지만 비즈니스 도메인간에 코드를 공유 할 수 있습니다.
Domain1 # This domain changes bits of standard MVC code
controllers
models
views
Domain2 # this domain only modifies views, all else is standard
views
Shared # Here is the better part of code base
controllers
models
views
추신. 대부분의 프레임 워크는 코드를 공유하고 별도의 프로젝트를 생성하는 경우에만 서로 다른 비즈니스 도메인을 단일 프로젝트로 혼합 할 것으로 기대하기 때문에 기술 영역별로 구성한다고 생각합니다 .
편집하다:
예를 들어 회사의 창고를 처리하는 웹 앱이 있다고 가정합니다. 일반적인 형태로 이것은 많은 회사에 적용될 수 있지만 각 회사는 충족되지 않은 일부 세부 사항을 가지고 있으며 구매를 금지 할 수 있습니다. 기본값이 2가 아닌 3 단계로 항목을 구성합니다.
물론 각 회사마다 프로젝트를 포크 할 수 있습니다. 그러나 프레임 워크 / 언어가 허용하는 경우 서브 클래 싱 또는 플러그인 등을 사용하여 일반 프로젝트의 비트와 조각을 모든 고객의 요구에 맞게 사용자 정의하고 비즈니스 도메인 레이아웃으로 구성 할 수 있습니다.
예를 들어 일반 프로젝트가 항목 자체 만 JSON으로 내보내는 경우 Domain1은 컨트롤러를 서브 클래스 화하고 최근 배달 문제도 내보낼 수 있습니다.
그리고 나중에 Domain1에 Domain2에도 유효한 구성 요소가있는 경우이를 일반 버전으로 공유로 추출 할 수 있습니다.
당신이 말했듯이, 많은 프레임 워크는 기술 영역별로 구성되며 이것이 내가 선택한 FW가 이것을 쉽게하기 때문에 지금까지 사용한 것입니다. 그러나 약간의 엘보우 그리스를 사용하면 비즈니스 도메인 레이아웃을 지원하기 위해 포함 경로를 다시 작성할 수 있다고 생각합니다.
답변
“정기적으로, 더 많은 도메인 또는 더 많은 기술 부서를 어떻게 추가 할 가능성이 있습니까?” 그렇다면 답이 무엇이든 최상위 레벨에 놓으십시오.
대부분의 경우 기술 아키텍처는 도메인보다 더 빠르게 강화됩니다. 즉, 먼저 도메인별로 구성한 다음 아키텍처 구성 요소별로 구성해야합니다. 그 이유는 도메인의 항목이 변경 될 때 해당 도메인의 여러 기술 구성 요소를 추가하거나 변경해야 할 수도 있지만 현지화되어 다른 도메인으로 많이 넘치지 않기를 바랍니다.
GUI 프레임 워크를 변경 한 경우 변경 내용이 전체 응용 프로그램에 유출되지만 GUI 프레임 워크는 거의 변경되지 않지만 항상 도메인 논리가 변경됩니다.
동시에 변경 될 가능성이있는 경우 함께 보관하십시오.
답변
또 다른 대안이 있으며 플러그인에서 별도의 부분을 옮기는 것입니다. CakePHP는 예를 들어 그렇게합니다. 재사용 가능한 완전한 MVC 부품을 생성하여 원하는 로직으로 정렬 할 수 있습니다.
기본 응용 프로그램은 사용하고 링크합니다.
기본적으로 귀하의 질문은 응집력과 결합에 관한 것입니다. 별도의 부품이 가능한 한 독립적으로 작동하기를 원합니다. 그렇게하면 테스트 가능하고 재사용 가능한 코드를 얻을 수 있습니다.
고려 사항 : 도메인별로 분리하면 응용 프로그램의 일부를 어떻게 재사용합니까? 예를 들어 webshop을 보자. / orders / view / 1에 대한 요청이 들어 오므로 order nr을 표시해야합니다. 1. / orders / controllers / order_controller로 이동합니다. 제품 및 주문별로 도메인을 분리 한 경우 이미 다른 “도메인”의 일부가 필요합니다.
거기에서 당신은 사물을 시작할 수 있지만 일이 대부분의 사업에 너무 응집력이 있습니다. 기술적 인 접근을하는 경우. 예를 들어 주문을 처리하는 플러그인이있을 수 있습니다. 중앙 애플리케이션에서 Product 오브젝트를 제품 오브젝트에 넣습니다. 그렇게하면 쉽게 플러그인을 테스트 할 수 있습니다. 이름과 가격으로 Product 객체를 생성하여 보내면됩니다.
플러그인은 필요한 작업을 정확하게 수행합니다. 다른 “부품 / 도메인 / 영역”이 아니라 입력에 의존합니다.
답변
Microsoft ASP.Net MVC 3에는 “영역”이라는 개념이 있습니다. MVC 프로젝트에 “Areas”를 도입하면 다음과 같이 분할됩니다.
area1/
models
views
controllers
area2/
models
views
controllers
나는 이것이 매우 자연스러운 것을 알았다. 영역은 프로젝트의 “큰 덩어리”이며, 독립된 단위로 작업하는 것은 많은 의미가있었습니다.
FWIW와 일치하도록 네임 스페이스를 사용했습니다.
답변
300,000 줄의 코드로 구성된 웹 상점에 대한 개인적인 경험을 통해 항상 비즈니스 도메인별로 구성하려고합니다. 이런 방식으로, 하나의 기능 영역에서 작업 할 때 모든 관련 클래스에 대한 빠른 개요를 얻을 수있을뿐만 아니라 Java에서는 패키지 가시성을 사용할 수도 있습니다.
관심있는 사람들을위한 몇 가지 세부 사항 : 프로젝트가 5 년 전에 시작되었을 때 개발자는 다음과 같은 패키지 구조를 만들었습니다.
com
example
web
struts
action
form
shared
functionality1
functionality2
쇼핑 카트, 제품 검색 등과 같은 각 상점 기능은 각각 고유 한 양식 클래스 (MVC 프레임 워크에서 규정 한 구조)를 가진 여러 조치로 구성됩니다. 우리가 끝낸 것은 액션 패키지에 200 개가 넘는 클래스로, 각 클래스는 관련 폼 클래스와 완전히 분리되어 있습니다. 더 나쁜 것은 동작이 너무 많은 로직을 구현하지는 않지만 또 다른 패키지에있는 기능별 서비스를 호출한다는 것입니다.
비즈니스 팀별로 패키지 구성으로 전환해야한다고 팀에 제안하고 설득했습니다. 추론은 간단합니다. 모든 작업 목록을 실제로 보려면 원하는 IDE의 유형 계층 구조보기를 열면됩니다. 그러나 IDE가 할 수없는 것은 클래스가 속한 비즈니스 도메인을 유추하는 것입니다. 또한이 접근 방식을 사용하면 여러 기능에 필요한 클래스 만 공개하여 나머지 패키지 가시성을 유지할 수 있습니다.
답변
많은 프레임 워크가 기술 영역별로 분리되어 있으므로 새 프레임 워크를 사용할 때 종종 이런 방식으로 시작한다는 데 동의합니다. 그러나 저는 비즈니스 도메인을 기본 수준의 폴더 구성으로 사용하는 데 일관되게 정착했습니다.
개인적으로, Foo 주변에 기능을 추가 할 때 컨트롤러 폴더와 리포지토리 폴더 사이를왔다 갔다하는 것보다 Foo Controller와 Foo Repository를 유지하는 것이 훨씬 쉽다고 생각합니다. 대규모 프로젝트에서는 기술 폴더 간의 거리가 길어 개발 중에 눈에 띄는 시간 낭비가되기 때문에 훨씬 더 중요합니다.