수명이 40 년 이상인 웹 응용 프로그램 설계에 대한 조언

대본

현재 저는 의료 서비스 제공자가 사용자 생성 양식을 사용하여 알 수없는 속성으로 데이터를 캡처하는 것이 주요 건강 관리 프로젝트입니다. 두 번째 요구 사항은 데이터 무결성이 핵심이며 40 년 이상 응용 프로그램을 사용해야한다는 것입니다. 우리는 현재 지난 40 년간 고객의 데이터를 다양한 소스 (Paper, Excel, Access 등)에서 데이터베이스로 마이그레이션하고 있습니다. 향후 요구 사항은 다음과 같습니다.

• 양식의 워크 플로우 관리
• 양식 일정 관리
• 보안 / 역할 기반 관리
• 보고 엔진
• 모바일 / 태블릿 지원

상태

단 6 개월 만에 현재 (계약 된) 건축가 / 고급 프로그래머가 "빠른"접근 방식을 취하고 열악한 시스템을 설계했습니다. 데이터베이스가 정규화되지 않았고 코드가 결합되어 있으며 계층에 전용 목적이 없으며 데이터베이스에서 "삭제"를 수행하도록 일부 Bean을 설계했기 때문에 데이터가 누락되기 시작합니다. 코드베이스가 부풀어 오르고 데이터베이스가 정규화되지 않았기 때문에 데이터를 동기화하는 작업이 있습니다. 그의 접근 방식은 누락 된 데이터를 복원하기 위해 백업 작업에 의존하는 것이 었으며 리팩토링을 믿지 않는 것 같습니다.

내가 찾은 결과를 PM에 제시 한 후, 건축가는 계약이 끝나면 제거됩니다. 이 응용 프로그램을 다시 작성하는 작업을 받았습니다. 우리 팀은 저와 한 명의 주니어 프로그래머로 구성되어 있습니다. 우리는 다른 자원이 없습니다. 우리는이 시스템을 재 구축하는 데 집중할 수있는 6 개월의 요구 사항 동결을 받았습니다.

Drupal과 같은 CMS 시스템을 사용하도록 제안했지만 클라이언트 조직의 정책상의 이유로 시스템을 처음부터 새로 만들어야합니다.

수명이 40 시간 이상인 시스템을 설계하는 것은 이번이 처음입니다. 나는 3-5 년의 수명을 가진 프로젝트에서만 일했기 때문에이 상황은 매우 새롭지 만 흥미 진진합니다.

질문

• 시스템을 "미래 증명"으로 만드는 디자인 고려 사항은 무엇입니까?
• 시스템을 "미래의 증거"로 만들려면 고객 / PM에게 어떤 질문을해야합니까?

데이터는 왕이다

2013 년경 웹 애플리케이션이 2053 년에도 여전히 가동되고 실행 가능할 것으로 예상하기에는 다소 비합리적이라고 생각합니다. 기술은 변할 것입니다. 플랫폼은왔다 갔다 할 것입니다. 그때까지 HTML은 기이 한 메모리 일 수 있습니다. 그러나 데이터는 여전히 주변에 있습니다.

따라서 데이터가 주요 초점입니다. 데이터가 여전히 존재하는 한 사람들은 새로운 기술이 무엇이든 적용 할 수 있습니다. 데이터 스킴이 잘 고려되고 확장에 적합해야합니다. 시간을내어 그것들을 지정하십시오.

실제 응용 프로그램과 관련하여 회사는 아마도 '처음부터 빌드'지시어를 사용하는 것이 맞을 것입니다. 저는 10 년 이상 된 웹 앱을 몇 개 유지하고 있으며 2003 년의 일반적인 CMS 시스템에 얽매이지 않아 매우 기쁩니다. 이들은 집에서 만든 매우 간단한 프레임 워크를 사용합니다. 나는 이와 같은 것을 당신이 프로젝트의 요구에 대해 specicularly 만드는 매우 기본적인 프레임 워크를 사용하는 것이 더 낫다고 생각합니다.

그러나 실제로 40 년이 넘게 회사는 진화하는 플랫폼에 적응하기 위해 상당히 많은 프론트 엔드 및 백엔드 서비스를 만들고있을 것입니다. 따라서 개별 사용자 대상 응용 프로그램의 수명은 5-10 년입니다.

우리는 20 년 이상 고객에게 지불함으로써 사용 된 소프트웨어를 생산합니다. 코드베이스는 여러 세대의 소스 제어 도구보다 오래 지속되었습니다. 우리의 소프트웨어는 태블릿을 제외한 모든 글 머리 기호에 부딪칩니다.

우려 사항 중 일부는 ESIGN 및 UETA 입니다. 변호사들은 전자 기록을 최소한 10 년 동안 읽을 수 있도록 유지해야한다고 생각합니다. 전체가 보관 된 문서의 경우 PDF / A를 살펴보십시오 .

데이터베이스의 경우 정규화에 대해 너무 걱정하지 마십시오. 대신 모든 사항을 기록하고 데이터의 변경 / 삭제를 추적하는 감사 테이블이 있어야합니다. 버전을 업그레이드 할 때 새 버전을 동시에 테스트하여 데이터를 마이그레이션했는지 확인하십시오. 이 새로운 버전의 테스트에는 새로운 운영 체제도 포함되어 있습니다. 우리는 수년간 매우 불쾌한 놀라움을 안겨 왔습니다. 롤백이 필요한 경우 설치 미디어 및 라이센스 키를 유지하십시오. 백업 테스트 데이터베이스에 저장할 객체를 직렬화하려는 경우 개발 프레임 워크에서 제공 한 직렬화 대신 XML로 수행하십시오.

직원을 위해 장기 코드 기반에는 장기 메모리가 필요합니다. 이상적으로는 오랫동안 주변에 있었던 사람들을 원할 것입니다. 그것이 제도적으로 불가능하다면, 위키와 같은 것으로 모든 것을 문서화해야합니다. 그리고 내 조언은 버그 추적 시스템과 연결할 수있는 위키입니다.

코드베이스의 경우 코드에 주석이 있는지 확인하십시오. 한 버전 제어 시스템에서 다른 버전 제어 시스템으로 마이그레이션하면 체크인 주석이 항상 손실됩니다. 나는 스펙과 버그 번호 다음에 이름 지정 단위 테스트의 팬입니다. 이렇게하면 단위 테스트 Test_Bug_1235 가 중단되면 테스트 대상 을 추적 할 대상과 위치를 알 수 있습니다. 테스트의 이름을 지정하는 것만 큼 "섹시한"것은 Check_File_Save_Networked_Drives아니지만 이러한 종류의 테스트는 사양, 요구 사항 또는 버그와 달리 역 추적하기가 어렵습니다 Test_requirement_54321_case_2.

이 응용 프로그램이 지금까지 20 년 동안 어떻게 운영 될지 알아 내려고 노력하기보다는 원래 건축가가 야기한 문제를 해결하기 위해 6 개월을 지내야하며 합리적이고 견고한 아키텍처를 구축해야합니다. 거기에서 앞으로 나아가십시오.

의료 환경에서 데이터베이스의 부분적인 비정규 화가 반드시 예상치 못한 것은 아닙니다. 의료 데이터베이스의 일부 부분에는 EAV (Entity / Attribute / Value) 모델에 적합한 특성이 있습니다.

프런트 엔드 관점에서 답변 :

1996 년에 공동 저술 한 샌프란시스코 주립대 학교 웹 서비스는 몇 년 전 인터넷 천국에 갔으며 그 당시에는 단일 브라우저 호환성 수정이 필요하지 않았기 때문에 모든 사람의 말을 듣지 마십시오. ; 40 년 목표의 거의 절반입니다. 그리고 1998 년 스탠포드 연구소 (Stanford Research Institute) 프로젝트를 위해 만든 이 JavaScript 기반 프론트 엔드 는 몇 년 후에 더 화려하게 바뀌었지만 오늘날의 UI가 여전히 약간의 호환성 수정으로 실행될 수 없었습니다.

비결은 앱이 광범위하게 지원되는 W3C / ECMA 표준 만 사용 하고 통제하에 깔끔한 디자인 을 갖도록하는 것 입니다. 트렌디 한 90 년대 기술로 작성된 많은 웹 앱이 제대로 작동하지 않거나 오늘날에는 효과가 없지만 주요 표준으로 작성된 90 년대 웹 앱은 여전히 ​​그렇습니다. 그들은 passé처럼 보일지 모르지만 작동합니다.

여기서 목표는 서버에 올라가서 다시는 손대지 않고 40 년 동안 웹 응용 프로그램을 작성하는 것이 아닙니다. 그것은 수십 년 동안 계속 사용할 수있는 기반을 구축하는 것입니다.이 기반은 처음부터 다시 작성하지 않고도 새로운 기능을 지원하도록 성장할 수 있습니다.

우선, 공식 표준 과 공식 표준 에만 코딩해야 합니다. 비준 된 ECMAScript 표준에 포함되지 않은 JavaScript 기능은 없습니다. ES5.1은 현재 버전이며 일반적으로 지원되므로 안전하게 타겟팅 할 수 있습니다. 마찬가지로 HTML5, CSS 및 유니 코드의 현재 버전이 좋습니다. 실험적인 JavaScript, CSS3 또는 HTML 기능 (공급 업체 접두사가 있거나 브라우저간에 100 % 동의하지 않은 기능)이 없습니다. 브라우저 별 호환성 해킹이 없습니다. 표준에있는 새로운 기능을 사용하기 시작하면 접두사없이 모두 지원할 수 있습니다.

ES5 지원은 IE8 또는 이전 버전을 제거하는 것을 의미합니다. 어쨌든 몇 년 동안 쓸모없는 브라우저 관련 해킹이 필요하기 때문에 제안합니다. 나는 ES5의 엄격한 모드를 장수했을 때 최상의 기회로 삼을 것을 제안합니다. 실제로 IE10과 다른 모든 사람들의 최신 버전 에서 기본 브라우저 호환성을 설정합니다 . 또한 이러한 브라우저는 HTML5의 여러 가지 양식 유효성 검사 및 자리 표시 자 기능을 기본적으로 지원하므로 매우 유용합니다.

ECMAScript의 새 버전은 이전 버전과의 호환성을 유지하므로 코드가 현재 표준에 따라 작성된 경우 향후 기능을 훨씬 쉽게 채택 할 수 있습니다. 예를 들어, 다음 class구문을 사용하여 정의 된 클래스는 현재 constructor.prototype구문으로 정의 된 클래스와 완전히 호환됩니다 . 따라서 개발자는 5 년 안에 클래스 단위로 파일을 기반으로 ES6 형식으로 클래스를 다시 작성할 수 있습니다. 물론 단위 테스트도 훌륭하다고 가정합니다.

둘째, 최신 JavaScript 앱 프레임 워크를 피하십시오 ( 특히 앱 코딩 방식이 변경되는 경우). 백본은 모든 분노 였고, SproutCore와 Ember는 이제 모든 사람들이 홍보하는 것을 좋아하는 프레임 워크입니다. 유용 할 수도 있지만 공통점이 있습니다. 새로운 버전이 출시되고 수명이 의심되는 경우 종종 앱을 중단하고 코드를 변경해야합니다. 최근에 Angular 1.1 앱을 1.2로 업데이트했으며 꽤 많이 다시 작성해야했습니다. 마찬가지로 Backbone 2에서 3으로 변경하려면 많은 HTML 변경이 필요합니다. 표준은 이유가 느리게 진행되지만 이러한 프레임 워크는 빠르게 이동하며 정기적으로 중단되는 것은 비용입니다.

또한 새로운 공식 표준은 종종 오래된 프레임 워크를 사용하지 않는 경우가 많으며, 이러한 프레임 워크가 발생하면 변경 사항이 변경되거나 변경됩니다. ECMAScript 6이 비준되고 모든 브라우저가 표준화 된 Promise 클래스를 지원하면 세계의 모든 경쟁 약속 라이브러리에 어떤 일이 일어날 지 알고 있습니까? 더 이상 사용되지 않으며 개발자가 업데이트를 중지합니다. 올바른 프레임 워크를 선택하면 코드가 충분히 적응할 수 있으며 잘못 추측하면 주요 리팩토링을 보게됩니다.

따라서 타사 라이브러리 또는 프레임 워크를 채택하려는 경우 향후 제거하기가 얼마나 어려운지 자문 해보십시오. Angular와 같은 프레임 워크 인 경우 앱을 처음부터 다시 작성하지 않고는 제거 할 수 없다면 40 년 아키텍처에서는 사용할 수 없습니다. 일부 사용자 정의 미들웨어로 추상화 한 써드 파티 캘린더 위젯 인 경우 교체하는 데 몇 시간이 걸립니다.

셋째, 좋은 앱 구조를 제공하십시오. 앱 프레임 워크를 사용하지 않더라도 개발자 도구, 스크립트 작성 및 깔끔한 디자인을 활용할 수 있습니다. 저는 개인적으로 Closure Toolkit의 종속성 관리를 좋아합니다. 가벼우면서 앱을 빌드 할 때 오버 헤드가 완전히 제거 되었기 때문입니다. LessCSS와 SCSS는 또한 스타일 시트를 구성하고 릴리스 할 표준 기반 CSS 스타일 시트를 작성하는 데 유용한 도구입니다.

MVC 구조를 사용하여 자체 코드를 일회용 클래스로 구성 할 수도 있습니다. 그러면 앞으로 몇 년 동안 더 쉽게 돌아와서 무언가를 쓸 때 생각했던 것을 알고 필요한 부분 만 교체 할 수 있습니다.

또한 W3C의 조언을 따르고 프레젠테이션 정보를 HTML에서 완전히 제외시켜야합니다. 여기에는 "big-green-text"및 "two-columns-wide"와 같은 프리젠 테이션 클래스 이름을 제공하는 것과 같은 치트가 포함됩니다. HTML이 의미론적이고 CSS가 프리젠 테이션 인 경우,이를 유지 보수 및 적용하기가 훨씬 쉬워집니다. 앞으로 새로운 플랫폼으로 또한 시각 장애인이나 장애인을위한 특수 브라우저에 대한 지원을 쉽게 추가 할 수 있습니다.

넷째, 테스트를 자동화하고 거의 전체 범위를 커버하는지 확인하십시오. 서버 측이든 JavaScript이든 모든 클래스에 대한 단위 테스트를 작성하십시오. 프론트 엔드에서 각 클래스가 지원되는 모든 브라우저에서 스펙에 따라 수행되는지 확인하십시오. 모든 커밋마다 빌드 봇에서 이러한 테스트를 자동화하십시오. 현재 브라우저에서 버그를 가리더라도 버그를 조기에 발견 할 수 있기 때문에 수명과 안정성 모두에 중요합니다. Jasmine과 Google Closure의 JSUnit 기반 테스트 프레임 워크 모두 좋습니다.

또한 Selenium / WebDriver가 능숙한 전체 UI 기능 테스트를 실행하고 싶을 것입니다. 기본적으로 UI를 단계별로 실행하여 마치 마치 마치 테스트하는 것처럼 사용하는 프로그램을 작성합니다. 빌드 봇에도 연결하십시오.

마지막으로, 다른 사람들이 언급했듯이 귀하의 데이터는 왕입니다. 데이터 스토리지 모델을 고려하여 오래 지속되도록하십시오. 데이터 스키마가 견고한 지 확인하고 모든 커밋에서 철저히 테스트해야합니다. 또한 서버 아키텍처가 확장 가능한지 확인하십시오. 이것은 프런트 엔드에서하는 것보다 훨씬 중요합니다.

고객의 불합리한 기대에 대한 문제를 제외하고 설계 문제에 중점을 둔다면 40 년은 걸리지 않았지만 장기적으로 진화 할 수있는 것으로 보이는 문제는 REST가 만들어 낸 것입니다. . 즉, 요즘 용어와 일반적으로 관련되는 유행어 중심 개발이 아니라 아키텍처 스타일로 REST를 의미합니다.

논문에 미디어 유형 디자인에 대한 충분한 세부 사항을 포함시키지 못했기 때문에 사람들은 어느 정도 REST를 잘못 얻습니다. REST의 다른 측면보다 덜 중요하다고 생각했기 때문에 시간이 부족했기 때문입니다. 마찬가지로, 나는 많은 사람들이 권위있는 출처에 근거하지 않은 주제에 대한 Wikipedia 항목 만 읽기 때문에 잘못 알고 있다고 생각합니다.

그러나 대부분의 사람들은 단순한 것을 디자인하는 것이 간단해야한다는 실수를 저지른 것 같습니다. 실제로, 무언가를 설계하는 데 필요한 노력은 결과의 단순성에 반비례합니다. 건축 스타일이 발전함에 따라 REST는 매우 간단합니다.

REST는 수십 년 규모의 소프트웨어 설계입니다 . 모든 세부 사항은 소프트웨어 수명과 독립적 인 진화를 촉진하기위한 것입니다.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

RESTful 인터페이스를 사용하겠다고 언급했습니다. 그 의견 자체는 당신이 그것에 대해 진지한 연구를하고 REST가 실제로 무엇인지 이해하려고 노력할 것을 제안합니다. 아마도 대부분의 사람들이 REST라고 생각하는 CRUD 작업에 HTTP 메소드를 매핑하는 것만으로 연관시킬 수 있지만 그와는 아무런 관련이 없습니다.

REST를 웹 아키텍처의 공식화로 생각하십시오. 어떤 식 으로든 10 년 전에 작성된 웹의 많은 부분이 여전히 사용 가능하고 오늘날 만들어진 클라이언트와 함께 사용할 수 있으므로 해당 부서에서 무언가를 얻었습니다. REST를 올바르게 수행하는 것은 어렵지만 장기적인 이점은 가치가 있기 때문에 많은 작업이 필요합니다.

질문과 다른 (매우 잘 생각 된) 답변을 읽은 후에도 2 센트를 남겨 두겠다고 생각했습니다. 참고 : 실제로 오래된 응용 프로그램 / 소프트웨어를 전혀 유지할 필요가 없습니다. 내가 참조로 사용하는 것은 개방 된 정부 데이터를 가져 와서 다른 형식으로 구문 분석하고 표시하는 자체 진행중인 취미 웹 응용 프로그램입니다. 이 앱은 내가 혼자가 아니고 정부가 어쨌든이 데이터를 제공 할 것이라고 발표 한 프로젝트로 시작했습니다 . 그래서 많은 것들이 시간이 지남에 따라 변한다는 것이 분명했습니다. 그리고 그들은했다. 내가 배운 것 :

• 미니 응용 프로그램으로 분할하십시오. 각자 자신의 임무를 완수 할 수 있습니다. 이로 인해 단일 부품을 매우 빠르고 안전하며 매우 쉽게 교체 할 수 있습니다. 그리고 다시 돌아 가야 할 때 왜 일이 발생하고 어떻게 발생하는지 돌아 다니는 것이 어렵지 않습니다. 본인이나 다른 사람이 나중에 무언가를 변경해야하는 경우 전체 부품보다 단일 부품을 교체하는 것이 더 쉽습니다.
• 서로 다른 부품 간의 통신에 사용되는 견고한 미들웨어 / 계층을 확보하십시오. 이 경우 JSON을 사용했지만 XML, ini 또는 유사한 표준도 좋습니다. 반복하기 쉽고 거의 모든 것으로 변형 될 수 있습니다. 모두 오랜 시간 동안 살아남을 입증 된 표준입니다. 기본 데이터 및 / 또는 스토리지 모델이 변경 되더라도. 각 앱은 특정 작업에 고유 한 데이터 스토리지를 사용할 수 있습니다. 따라서 작업에 대한 스캔 데이터의 양이 줄어들 기 때문에 취급 및 유지 관리가 쉽고 교환이 쉽습니다.
• 프로그래밍 언어 결정에 대해 걱정하지 마십시오. 시간이지나면서 바뀔 것입니다. 자신에게 익숙하거나 작업에 가장 적합한 언어를 사용하십시오.
• 데이터 스토리지가 "가로 확장 가능" 하고 추가 스토리지 모듈을 쉽게 연결할 수 있는지 확인하십시오 .
• 미니 앱이 호출 및 / 또는 데이터를 교환하는 공통 지점 (제 경우에는 URI)을 가져옵니다.

요약 : 내가 가장 중요하게 생각하는 것은 작업에 할당 된 부품의 관심사 분리 및 교환 가능성입니다. 하드웨어, 인터페이스, 스토리지 등이 40 년 (5 년 또는 10 년이라도)에 크게 변할 것입니다. 그리고 나중에 개발자는 이러한 변경에 대응하고 데이터 컨테이너 또는 사용자 인터페이스의 일부인 응용 프로그램의 일부를 교환해야합니다.

가능한 한 "미래에 대비 한"것을 만들려면 변화를 계획하십시오. 즉, 쉽게 바꿀 수있는 능력 이외의 다른 것에 최적화하지 않도록 노력하십시오. 따라서 정규화, 엄격한 유효성 검사 및 느슨한 커플 링이 없습니다.

• 주요 오픈 소스 기술을 사용하십시오. 데이터의 경우 폐쇄 소스 시스템은 데이터에 대한 모든 액세스 권한을 사용하여 어떤 회사가 전략을 밟거나 전략을 변경할 것인지 계획 할 수 없으므로 주요 위험의 원천입니다. 또한 활기찬 커뮤니티가없는 소규모 오픈 소스 프로젝트도 지원을 잃을 가능성이 높습니다.

• 스키마가없는 NoSQL 데이터베이스를 사용하십시오. 사용되는 비정형 데이터의 종류는 MongoDB와 같은 문서 저장소에 대한 교과서와 거의 동일합니다. 기존의 관계형 데이터베이스와 정규화는 데이터가 어떻게 구성 될지 알 때 유용하지만 특히 허구입니다. RDBS에서 스키마를 변경하는 비용은 시스템이 확장됨에 따라 점점 커집니다. 지금 선택한 구조가 무엇이든 바뀌게 될 것입니다.

• 널리 인정 된 표준을 사용하여 시스템을 크게 분리합니다. 모든 데이터 액세스 및 변이를 웹 서비스로 나누는 것이 한 가지 단계입니다. 변경 사항을 제출하기 위해 메시지 대기열과이를 결합하면 시스템의 개별 부분이 시간이 지남에 따라 언어 나 기술을 변경하는 데 도움이됩니다.

좋아, 아마 여기에 꽤 인기가 없을 것 같은 것들을 말하려고하지만, 여기에 나와 붙어 있습니다.

데이터 및 / 또는 응용 프로그램이 20 년 이상 지속되어야하는 첫 번째 프로젝트이므로 프로젝트를 주도하는 프로젝트이므로 한 걸음 물러서서이 프로젝트의 성공 가능성에 대해 생각해야합니다. . 기본적으로 0 옆에 있기 때문입니다.

데이터베이스 디자인에 초점을 맞추고 제대로 작동하려면 많은 시간을 소비해야합니다. 이 프로젝트가 성공하려면 데이터 아키텍트를 프로젝트로 가져와야합니다. 데이터베이스 설계에 경험이있는 사람이없고 미래에 데이터를 어떻게 사용할 수 있을지에 대해 잘 알고있는 사람이 없으면 5 년이 지나도 40 년이 훨씬 지난 후에도 여전히 유용한 데이터의 가능성은 어느 누구에게나 미미합니다.

40 년 동안 지속될 것으로 예상되는 무언가를 처음부터 구축하기 위해 두 사람 (한 명은 jr.dev라는 제목을 가짐)을 기대하면 성공하지 못할 것입니다. 데이터 디자인, API 디자인 및 응용 프로그램 디자인을 다루는 이와 같은 대규모 프로젝트를 수행 한 경험이 많은 사람들로 구성된 팀이 있어야합니다. 이와 같은 것은 2 인 프로젝트가 아닙니다.

Drupal과 같은 프로젝트에 프로젝트를 연결하려는 이유는 프로젝트에 이러한 종류의 프로젝트를 수행하는 데 익숙한 사람들이 필요한 이유를 보여줍니다. 몇 년 내에 스타일이 떨어질 수있는 응용 프로그램과 응용 프로그램을 묶고 싶지 않습니다. 그렇다면 5-10 년 안에 시스템에서 일할 사람을 찾는 것이 매우 어려울 수 있습니다.

나는이 조언을 경영진에게 가져 가서 프로젝트에 더 많은 고위 직원을 고용해야한다고 설명합니다. 그렇지 않으면 프로젝트가 실패 할 가능성이 높으며 결국 그 책임을지는 프로젝트가 될 수 있습니다.

응용 프로그램은 진화없이 40 년 동안 생존 할 필요가 없습니다. 그러나 처음부터 새로 작성하거나 빌드해야하므로 여전히 '기능적'일 수 있습니다.

가장 중요한 것은 안정성과 거버넌스 및 확장 성을 허용하는 '데이터 아키텍처'입니다.

우리는 인류의 끝에서 살아남을 수 있지만 여전히 확장 가능한 데이터 아키텍처 및 분류법을 설계했습니다. 이를 위해 진정한 DATA TAXONOMY / DATA ARCHITECTURE 사람을 찾으십시오.

여기서 핵심은 데이터베이스에 초점을 맞추는 것입니다 (위의 몇 가지 말했듯이). 이것은 일관되고 작업을 완전히 설명해야합니다. 작업이 변경됨에 따라 확장해야합니다. 변경하기가 쉽지 않으면 구식이되어 죽음의 입맞춤입니다. 나머지는 상대적으로 덜 중요합니다.

현재 시스템이 작동하지 않는 경우가 항상 있지만 정규화가 중요하지 않다고 제안하는 사람들은 동의하지 않습니다. 이러한 경우 비정규 화되지만 데이터베이스가 원자 트랜잭션의 일부로 추가 쓰기 / 변경을 처리하도록합니다. 이렇게하면 문제를 해결할 수있을 때까지 문제를 효과적으로 무시할 수 있습니다.

퇴직 전에 제가 일했던 회사는 처음부터 새로 작성되었고 25 년 동안 거의 지속적으로 성장한 시스템을 운영하고 있으며 거의 ​​모든 소매 업체의 모든 측면을 다루고 있습니다. 내가 중요하다고 생각한이 시스템의 측면은 다음과 같습니다.

• 통합이 중요합니다.
• 데이터베이스는 IT 직원과 다른 직원 모두에게 정확하고 이해 가능해야하므로 이름 지정에 거의 편집증적인 강조가 필요합니다. 정의 된 니모닉 테이블이 있으며 테이블과 필드 이름을 구성하기 위해 결합되며 모든 "코드"도 마찬가지로 상수로 명명되어 EAV 테이블 구조에 저장됩니다.
• 비즈니스 로직을 데이터베이스 트리거로 캡슐화했습니다. 이것은 처음에는 고통스럽고 클라이언트에게 오류 메시지를 전송하고 일부 시스템에서 전체 테이블을 잠그지 않고 트리거를 유연하게 변경하기 위해 추가 작업이 필요하지만, 이로 인해 시간이 크게 단축되고 데이터베이스가 훨씬 더 정확 해집니다. 그렇지 않으면
• 참조가 올바르도록 "삭제"된 경우에도 시스템 수명 동안 최소한 참조 테이블 (이상적으로 가장 빠르고 가장 중요한 트랜잭션을 제외한 모든 참조 테이블)을 유지한다고 가정하십시오.
• 위의 이유로 인해 고유 식별자와 트랜잭션 번호의 크기가 장기적으로 유지됩니다. (나는 원래 농담으로 그들이 은퇴 할 때까지 지속해야한다고 제안했다).

이벤트 소싱 과 명령 및 쿼리 책임 분리를 사용하는 것이 좋습니다 . 이것은 당신이 확신 할 수있는 유일한 것은 이미 나타난 사건이기 때문입니다. 새로운 유형의 이벤트가 올 수 있습니다. 따라서 모델에 대해 많은 생각을하더라도 이것이 구식이 될 것입니다. 모든 릴리스에서 모든 데이터를 마이그레이션하는 것이 가능하지 않을 수 있습니다. 따라서 최선의 방법은 현재 요구에 맞는 모델을 보유하고 필요할 때마다 이미 기록 된 이벤트에서 계산 한 다음 해당 모델의 현재 상태에서 계산 된 이벤트를 전달하는 것입니다.

또한 테스트를 염두에 두십시오. 지금부터 10 년 안에 응용 프로그램을 사용중인 경우 테스터는 여전히 수행해야하는 작업을 수행하고 있는지 확인해야합니다. 따라서 응용 프로그램을 가능한 한 쉽게 통합 테스트하십시오.