자바 애플리케이션 구조 : 수평 대 수직 분할

대규모 Java 애플리케이션을위한 시작 프로젝트 구조 (Maven / Eclipse 사용)에 대해 약간의 토론이 있습니다.

옵션 1:

entities (i.e. the whole database using Hibernate classes-first)
services (i.e. sets of read/write operations on the entities)
app (perhaps split up more further down the line)

옵션 2 :

area1-entities
area1-services
area1-app
area2-entities
area2-services
area2-app
...
(where area1, area2 etc. are functional areas of the system)

옵션 2는 훨씬 더 많은 Maven 프로젝트 / 모듈을 제공 할 것이므로 데이터베이스를 생성하는 클래스가 여러 프로젝트에 분산되어 있음을 의미합니다. 누구나 각 접근법의 장단점을 조언 할 수 있습니까?

나는 둘 다하지 말 것을 제안합니다.

패키지 구조로 기술 계층을 적용하려고하면 응용 프로그램에 많은 얽힘이 발생합니다. 우리가 서비스 인터페이스 뒤에 모든 것을 숨기려고 열심히 노력한다는 사실은 말할 것도없고, 우리가하는 첫 번째 일은 (주로 포장으로 인해) 모든 것을public class . a x.y.z.service와 x.y.z.repository패키지 가 기술적으로 분리되어 있으면 모든 것이 저장소에 액세스 할 수있게되면 문제가됩니다. 서비스 계층 내부에서 캡슐화가 진행됩니다.

대신보다 기능적이고 양파 기반의 접근 방식 ( 깨끗한 아키텍처 , 육각형 아키텍처 )을 따라야합니다 . 이것은 또한 단일 책임 원칙 (패키지에 적용될 때)과 잘 일치하며 포장 원칙에 따라

1. 함께 바뀌는 것들이 함께 포장됩니다
2. 함께 사용되는 것들이 함께 포장됩니다

Oliver Gierke는 Java로 구성 요소를 함께 패키징 하는 것에 대한 훌륭한 글 을 작성 했습니다 . 사이먼 브라운은 더 일반적인 이야기를 썼습니다 주제에 를 .

다음과 같은 핵심 패키지 구조를 사용하여 응용 프로그램의 핵심을 유지하려고합니다.

x.y.z.area1
x.y.z.area2

이제 웹 web서비스 ws또는 웹 서비스에 대한 하위 패키지와 같은 웹 인터페이스 rest가있는 경우 해당 패키지 만 보유합니다. 기본적으로 코어에 연결됩니다.

x.y.z.area1.web
x.y.z.area1.ws
x.y.z.area2.rest

이제 코어 내부의 객체를 다른 레이어로 재사용하는 것을 고려할 수 있지만 IMHO는 해당 레이어에 특정 도메인을 사용하는 것이 좋습니다. 마찬가지로 Object to SQL 매핑과 마찬가지로 화면에 표시하거나 웹 서비스에서 XML로 사용하려는 것과 비즈니스 로직이 구현되는 방식이 일치하지 않는 경우가 종종 있습니다. 비즈니스 도메인과 웹 도메인의 복잡성에 따라 연결해야하는 문제를 해결하기 위해 별도의 문제 도메인으로 간주 할 수 있습니다. 기본적으로 서로 다른 두 가지 컨텍스트 .

CQRS 리소스에서 인용을 사용하려면

단일 모델을 사용하여 트랜잭션을 검색,보고 및 처리하기위한 최적의 솔루션을 만들 수 없습니다.

모든 것을 단일 (도메인) 모델에 넣지 말고 책임을 분리하십시오. 아마도 더 작은 클래스이지만 응용 프로그램 계층 사이를 더 명확하게 구분할 수 있습니다.

최종 노트

아키텍처를 만드는 것은 한 솔루션과 다른 솔루션의 균형을 결정하는 것을 기억하십시오. 도메인의 복잡성에 따라 크게 달라지며 주로 응용 프로그램의 기능 요구 사항에 따라 달라집니다. 그러나 비 기능적 (성능, 보안) 및 환경 적 제약 (사용 언어, ​​플랫폼, 경험)의 영향을받습니다. 코딩과 같은 아키텍처는 결코 끝나지 않습니다. 각각의 새로운 요구 사항으로 인해 응용 프로그램을 다시 디자인 할 수 있습니다.

기권

그렇습니다. 또한 모든 것을 단일 모델로 만들려고했으며, 응용 프로그램에서 기술적 분리를 사용하려고했습니다. 그러나 얽힌 응용 프로그램 계층을 만드는 데 2 ​​년의 경험을 쌓은 후에 (처음에는 좋은 생각 인 것처럼 응용 프로그램이 커지기 시작합니다 ...) 다른 방법이 있어야한다고 생각했습니다.

연결

1. 깨끗한 건축, 밥 마틴 아저씨
2. 육각형 아키텍처 (일명 포트 및 어댑터), Alistair Cockburn
3. 올리버 지 에르케 (Oliver Gierke)
4. OOD의 원칙, Bob Martin 아저씨
5. UDD Dahan DDD 신청시 실수
6. 제한된 맥락, 마틴 파울러
7. 사이먼 브라운, 건축 적으로 명백한 코딩 스타일

서적

1. 테스트에 따라 성장하는 객체 지향 소프트웨어
2. Java 응용 프로그램 아키텍처 : OSGi를 사용한 예제가 포함 된 모듈성 패턴 (Robert C. Martin Series)
3. 도메인 중심 설계 : 소프트웨어 중심의 복잡성 해결
4. 개발자를위한 소프트웨어 아키텍처
5. 도메인 기반 디자인 구현