[SPRING] 기능별 접근 방식은 좋은 방법입니까? [닫은]

기능별 접근 방식은 좋은 방법입니까? [닫은]

최근에 필자는 기능별 패키지 자바 코드 http://java.dzone.com/articles/how-changing-java-package에서이 javalobby 게시물을 발견했다.

나는 그 아이디어가 마음에 들지만이 접근법에 대해서는 몇 가지 질문이있다. 나는 나의 질문을했지만 만족스러운 답을 얻지 못했다. StackOverflow에있는 누군가가 내 질문을 명확히 해주기를 바랍니다.

필자는 코딩을하는 동안 패키지를 이동하는 시간을 대폭 줄여주는 패키지 별 아이디어를 좋아합니다. 모든 관련 항목은 한 곳 (패키지)에 있습니다. 그러나 서로 다른 패키지의 서비스 간 상호 작용은 어떻습니까?

우리가 블로그 앱을 만들고 있다고 가정하고 com.mycompany.myblog.users 패키지에 모든 사용자 관련 작업 (컨트롤러 / 서비스 / 리포지토리)을 배치하려고합니다. 그리고 모든 블로그는 com.mycompany.myblog.posts 패키지의 관련 작업 (컨트롤러 / 서비스 / 리포지토리)을 게시합니다.

이제는 그가 게시 한 모든 게시물과 함께 사용자 프로필을 표시하려고합니다. myblog.perss.PostsService.getPostsByUser (userId)를 myblog.users.UserController.showUserProfile ()에서 호출해야합니까?

패키지 간 커플 링은 어떨까요?

또한 기능별 패키지에 대해 읽은 곳마다 모든 사람들이 좋은 습관을 말합니다. 그렇다면 왜 많은 책 저자와 프레임 워크가 레이어별로 그룹화하는 것이 좋습니다? 그냥 궁금해서 :-)

해결법

1. ==============================

   1.삼촌 Bob의 패키지 디자인 원칙을 살펴보십시오. 그는 그 원칙들에 대한 이유와 동기를 설명합니다. 나는 아래에 자세히 설명했습니다.

   삼촌 Bob의 패키지 디자인 원칙을 살펴보십시오. 그는 그 원칙들에 대한 이유와 동기를 설명합니다. 나는 아래에 자세히 설명했습니다.

   함께 재사용되는 클래스는 함께 패키징되어 패키지가 완전한 종류의 제품으로 취급 될 수 있도록해야합니다. 함께 재사용되는 것들은 재사용되지 않는 것들과 분리되어야합니다. 예를 들어 로깅 유틸리티 클래스가 파일 io 클래스와 함께 사용되는 것은 아닙니다. 따라서 모든 로깅을 별도로 패키지화하십시오. 그러나 로깅 클래스는 서로 관련 될 수 있습니다. 따라서 더 나은 이름을 원한다면 로깅을위한 일종의 제품을 만드십시오. 더 나은 이름을 원한다면, 다시 사용할 수있는 병에 패키지를 로깅하고, 유틸리티를 위해 또 다른 별도의 완전한 제품을 만들어야합니다. io.jar. java-nio를 지원한다고 말하는 commons-io 라이브러리를 업데이트하면 반드시 로깅 라이브러리를 변경하려고하지 않을 수도 있습니다. 그래서 그들을 분리하는 것이 좋습니다.

   자, 로깅 유틸리티 클래스가 splunk와 같은 도구에 의한 일종의 로그 분석을 위해 구조화 된 로깅을 지원하기를 원한다고 가정 해 봅시다. 로깅 유틸리티의 일부 클라이언트는 최신 버전으로 업데이트하려고 할 수 있습니다. 다른 사람들은 그렇지 않을 수도 있습니다. 따라서 새 버전을 출시 할 때 필요한 모든 클래스를 패키징하고 마이그레이션을 위해 함께 다시 사용하십시오. 따라서 유틸리티 클래스의 일부 클라이언트는 이전 commons-logging jar를 안전하게 삭제하고 commons-logging-new jar로 이동할 수 있습니다. 일부 다른 고객은 오래된 항아리에서 여전히 괜찮습니다. 그러나 오래된 패키지 병에 대해 몇 가지 클래스를 사용하도록 강요했기 때문에이 두 병 (새 클래스와 이전 클래스)을 모두 보유 할 클라이언트가 필요하지 않습니다.

   주기적 종속성을 피하십시오. a는 b에 의존한다. b on c; d에 c; 그러나 d는 a에 달려있다. 이 시나리오는 레이어 나 모듈 등을 정의하는 것이 매우 어려우므로 명백히 억제되어 있으며 서로에 대해 독립적으로 변경할 수는 없습니다.

   또한 레이어를 변경하여 레이어 또는 모듈이 변경된 경우 다른 모듈 또는 레이어를 반드시 변경하지 않아도되도록 클래스를 패키지화 할 수 있습니다. 예를 들어, 이전 MVC 프레임 워크에서 나머지 API 업그레이드로 이동하려면보기 및 컨트롤러 만 변경해야 할 수 있습니다. 귀하의 모델은 그렇지 않습니다.

2. ==============================

   2.패키지 디자인을위한 커플 링 이외의 많은 다른 측면은 OOAD 원칙, 특히 다음과 같은 패키지 디자인 원칙을 살펴볼 것을 제안합니다.

   패키지 디자인을위한 커플 링 이외의 많은 다른 측면은 OOAD 원칙, 특히 다음과 같은 패키지 디자인 원칙을 살펴볼 것을 제안합니다.

   REP 릴리스 재사용 동등성 원리 재사용의 과립은 릴리스 과립입니다.

   CCP 공통 폐쇄 원칙 함께 변경되는 클래스는 함께 패키지화됩니다.

   CRP 공통 재사용 원칙 함께 사용되는 클래스는 함께 패키지화됩니다.

   ADP The Acyclic Dependencies Principle 패키지의 의존성 그래프는주기가 없어야합니다.

   SDP 안정적 종속성 원칙 안정성의 방향에 따라 달라집니다.

   SAP The Stable Abstractions Principle 추상화는 안정성과 함께 증가합니다.

   자세한 내용은 "애자일 소프트웨어 개발, 원리, 패턴 및 실습"

3. ==============================

   3.필자는 개인적으로 "패키지 별 기능"접근법을 좋아하지만 패키지 경계를 그리는 위치에 대해 많은 판단을해야합니다. 많은 경우 상황이 실현 가능하고 합리적인 방법입니다.

   필자는 개인적으로 "패키지 별 기능"접근법을 좋아하지만 패키지 경계를 그리는 위치에 대해 많은 판단을해야합니다. 많은 경우 상황이 실현 가능하고 합리적인 방법입니다.

   공용 인터페이스를 사용하여 패키지와 모듈 간의 결합을 달성해야합니다. 이렇게하면 커플 링을 깨끗하고 관리하기 쉽게 유지할 수 있습니다.

   잘 설계된 공개 인터페이스를 사용하는 한 "블로그 게시물"패키지가 "사용자"패키지를 호출하는 것은 완벽합니다.

   하나의 커다란 조언이 있는데,이 접근법을 따르는 경우 : 의존성에 대해 매우 신중해야하며 특히 패키지 간의 순환 의존성을 피하십시오. 좋은 디자인은 의존성 트리처럼 보일 것입니다. 유틸리티 기능 라이브러리에 의존하는 공통 서비스 집합에 따라 상위 수준의 기능 영역이 있습니다. 어느 정도까지는 프론트 엔드 아키텍처가있는 아키텍처 "계층"처럼 보이기 시작합니다. 백엔드 서비스를 호출하는 최종 패키지를 제공합니다.

from https://stackoverflow.com/questions/11733267/is-package-by-feature-approach-good by cc-by-sa and MIT license