프로젝트 아키텍처 레거시 프로젝트 향상을 위해

Question

나는 레거시 프로젝트를 작업 중이다. 이제 상황은 프로젝트가 부분으로 으로 나뉘도록 요구합니다. 이 작업을 수행하려면 어떤 전략을 따라야합니다.

설명 :

레거시 프로젝트 (A)는 거의 잘 정의 된 레이어와 완벽하게 기능을 웹 응용 프로그램입니다. 하지만 지금은 프로젝트를 더욱 발전시켜야합니다. 이 프로젝트 사용법 빌드 도구. 그러나 이는 종속성 관리에만 사용됩니다. (프로젝트는 일식 안에서 전쟁 형태로 수출되었다).

새로운 기능으로 새 데이터 테이블, 새 UI (jsp, css, js 및 이미지)를 추가해야합니다.

응용 프로그램을 개선하기위한 내 전략은 무엇이되어야합니다.

제안 된 디자인.

나는

프로젝트 B 두 개의 새로운 프로젝트를 만들 기획하고 있습니다 : 홈페이지 개선 작동이 프로젝트에서 수행됩니다. 서비스 레이어, DAO 레이어 및 UI 레이어 자체가 모두 개의 레이어를 갖습니다. 그리고 웹은 그 자체가 될 것입니다.

프로젝트 C : 일부 일반적인 모델 및 프로젝트 코드 양식을 추출하고 이 프로젝트를 만듭니다. 이 프로젝트는 두 프로젝트 모두에 대한 종속성으로 추가됩니다.

내 접근 방식이 괜찮 으면! 그렇다면 배치에 문제가있을 것으로 예상됩니다. 이 두 프로젝트는 별도로 배포해야합니다 (현재는 tomcat 이 사용됩니다). 그러나이 두 프로젝트를 하나의 전쟁으로 전개해야합니다. 따라서 두 프로젝트의 구성을 포함하도록 web.xml 항목을 변경하려는 계획이 필요합니다. 이것은 프로젝트와 좀 더 복잡해질 것입니다.

프로젝트의 디자인은 어떻게해야합니까? 내 계획이 좋게 들리니?

Answer 1

저는 여러분의 개발을 동일한 '프로젝트'및 배포 단위의 일부로 유지할 것입니다. 그렇지 않으면 실제 요구 사항이나 아키텍처가 필요하지 않을 때 분리됩니다.

그러나 기존 코드 기반에 영향을주는 개선 사항에 대한 변경의 어려움을 설명하고 있습니다. 이 문제를 해결하려면 소스 제어 도구에 분기를 만들고 분기 개발을 향상시키는 것이 좋습니다. 이를 통해 라이브 코드베이스 (버그 픽스 등이 여전히 적용될 수 있음)에 영향을주지 않고 완전히 개발하고 테스트 할 수 있습니다.

완전히 테스트했으면 브랜치를 기본 코드베이스로 다시 병합하고 전체 애플리케이션이 작동하기 전에 릴리스되기 전에 최종 회귀 테스트를 수행 할 수 있습니다.

Answer 2

일반적인 접근 방식은 매우 합리적인 (공통 서비스 계층 - 프로젝트 C -를 분리하고 그 위에 A와 B를 쌓음). 나는 그것을 상당히 일상적이라고 부를 것이다.

프로젝트 A와 B의 특정 관계에 대해 혼란 스럽습니다.보다 정확하게 프로젝트 A와 B를 별도로 배포해야하지만 동일한 프로젝트의 일부가되어야하는 이유는 무엇입니까?

Answer 3

프로젝트를 엎 지르라는 요구 사항은 무엇입니까?

레거시 시스템이 잘 구성되어 있다면 레거시 프로젝트에 새 코드를 추가하기 만하면됩니다.

분할해야 할 경우 새 시스템이 레거시 시스템의 기능과 대화하는 데 사용할 "부패 방지 계층"을 구축 할 수 있습니다. 이렇게하면 기존 시스템에서 전혀 변경하지 않아도됩니다.