회사 A에 대해 수행되는 Grails 응용 프로그램이 있습니다. 이제 회사 B에 적용 할 몇 가지 변경 사항이 있습니다.
전체 프로젝트를 복제하고 싶지 않습니다. (코드 중복, 하드 관리, 양면 버그 수정 등)
대신 회사 고유 코드 파트와 동일한 프로젝트를 갖고 싶기 때문에 "회사 = A이면 ... ".
차이점은 클래스 수준 (각 회사에 대해 별도의 클래스 파일) 또는 코드의 작은 부분 (80 % 동일한 코드 + 20 % 회사 특정 코드가있는 동일한 클래스) 일 수 있습니다.
동일한 Grails 프로젝트를 구성 가능한 코드 부분과 함께 사용하여 A 사 또는 B 사 프로젝트를 별도로 구축 할 수있는 가장 좋은 방법은 무엇입니까?다른 환경 (회사)에 대해 1 Grails 응용 프로그램이있는 경우
프로젝트를 모듈 및/또는 플러그인으로 분해하십시오. 두 회사의 앱에 공통적 인 부분이있을 것이며 회사의 특성을 제공하는 기능을 확장 할 것입니다.
은 또한 그것은 모든 데이터 세트가 될거야 얽혀 방법에 따라 달라집니다 독립 실행 형 (마이크로) 서비스
이후 분해하기가 어렵습니다. 1. 다음 회사의 변경 사항은 무엇인지 미리 알지 못합니다. 2. 변경 사항은 전체 공통 로직 내부의 매우 작은 코드 블록이 될 수 있습니다. 예를 들어 gsp 파일에는 다른 데이터 행이 있습니다 다른 회사에 있지 않아야하는 회사의 경우 플러그인 또는 서비스로 각 작은 부분을 갖게되면 가독성에 영향을주는 많은 양의 플러그인 또는 서비스가 생성됩니다. – Artin
이를 해결하기위한 접근 방법이 많습니다. 앱 A를 B로 복사하고 B를 적절하게 변경 한 다음 두 앱을 비교하고 공유하는 공통 부분을 볼 수 있습니다. 어떤 부분은 핵심으로 추출 될 수 있고 다른 부분은 매개 변수화 될 수 있습니다 – injecteer
인젝터에 동의해야합니다. 네가 맞다면, 회사 2, 3, 또는 n의 변경 사항을 미리 알 수 없다. 작은 차이점은 설정 값을 통해 코드에서 처리 할 수 있습니다. 더 큰 차이점은 빌드 구성을 통해 회사 별 플러그인에서 바꿀 수 있습니다. 현재 잘 디자인 된 플러그인으로 리팩터링하여 미래의 고통을 완화 할 수 있습니다. – railsdog
로 응용 프로그램의 특정 부분을 변환 생각할 수 있습니다. 뿐만 아니라 나는 얼마나 광대하게 변화 할 것인가? 플러그인으로 분할하는 것이 불가능하고 데이터가 동일한 데이터베이스에 있고 고양이가 여전히 개가 아닌 고양이의 회사가 될 것이라면 괜찮습니다. 그런 다음 전체 비즈니스 클래스에 따라 확장 한 후 확장 된 값에 대한 구체적인 저장 방법을 사용하여 기본 클래스를 만드는 방법을 살펴볼 수 있습니다.
멀티 테넌트 아키텍처로 이동해야한다고 생각합니다. https://en.wikipedia.org/wiki/Multitenancy – Abs