2017-11-30 18 views
0

다른 계층 (도메인 서비스, 도메인 엔티티, 모델, 컨트롤러, fasade ...)에서 여러 모듈을 많이 가지고 있다면 초보자이거나 방황하는 것입니다. 모듈을 그룹화하고 하위 모듈 sub-sub를 만들어야합니다. -modues 등등. 내 프로젝트는 현재 이렇게 보입니다. 내 접근 방식에 뭔가 나쁜 점이 있습니까? 나는 단지 그 단점과 당신이 어떻게 다르게 할 것인지를 알고 싶습니다. :)서브 모듈로 봄 부팅 또는 제외?

My project structure

아니면 그들이 모두 흩어져과 함께 (나는 100 개 이상의 모듈이있는 경우 무엇을) 혼합 될 것이다이 경우, 프로젝트의 루트 디렉토리에 모두 넣어한다, 나는이 느낌 나쁜 접근이다. 아니면 내가 틀렸어? 그러나 특정 모듈을 변경하고 싶다면 하나의 루트 pom.xml 파일을보고 하위 모듈, 하위 모듈 및 pom.xml을 보지 않고 변경해야합니다. 거기에 변화.

+0

나는 어쩌면 당신은 당신이 어떻게해야하는지 아이디어를 얻을 것이다이 구조를 살펴 보자 https://github.com/nazaryan/ShipIt/tree/bootintegration2/src/main/java/com/를 nkwebapps/shipit 귀하의 질문에 대하여 "100 개 이상의 모듈을 가지고 있다면 어떻게 될까?"나는 100 개 이상의 모듈을 가져야 할 필요가 있다면 클래스 그룹을 논리적으로 분리하는 것이 중요하다고 말하고 싶습니다. 그리고 하나의 작은 충고가 "단일 책임"설계 원칙을 완전히 이해하는지 확인하십시오 – haykart

답변

0

나는 모듈의 역할을 오해하고 있다고 생각한다. 프로젝트를 여러 모듈로 나누는 것은 예를 들어 라이브러리의 경우 프로젝트의 일부 소비자 만 클래스의 하위 집합 만 필요하거나 라이브러리의 개발자가 공개 API와 개인 구현 간의 명확한 구분 그리고 큰 프로젝트를 사용하면 코드가 기술적으로 모두 동일한 모듈에있을지라도 코드를 순서대로 유지하기가 더 쉽습니다.

적절한 포장이 필요한 경우 많은 도움이됩니다.

For Example: 
All entity classes inside com.example.entity package 
All service classes inside com.example.service package and so on 
+0

나는 당신에게 동의하지 않습니다. 분리 된 모듈은 Maven 모듈에서도 표현되어야하는 관심사의 분리를 의미합니다 ... 배치가 모듈을 만들지 말아야 할 이유는 아닙니다 ... – khmarbaise