Porady na temat projektowania aplikacji internetowych o ponad 40-letnim okresie użytkowania

Scenariusz

Obecnie jestem niezależny od projektu opieki zdrowotnej, którego głównym wymaganiem jest przechwytywanie danych o nieznanych atrybutach przy użyciu formularzy generowanych przez użytkowników przez dostawców usług medycznych. Drugim wymogiem jest, aby integralność danych była kluczowa i aby aplikacja była używana przez ponad 40 lat. Obecnie migrujemy dane klienta z ostatnich 40 lat z różnych źródeł (papier, Excel, dostęp itp.) Do bazy danych. Przyszłe wymagania to:

• Zarządzanie przepływem formularzy
• Zaplanuj zarządzanie formularzami
• Zarządzanie oparte na bezpieczeństwie / rolach
• Silnik raportowania
• Obsługa urządzeń mobilnych / tabletów

Sytuacja

Już po 6 miesiącach obecny (zakontraktowany) architekt / starszy programista zastosował podejście „szybkie” i zaprojektował zły system. Baza danych nie jest znormalizowana, kod jest sprzężony, warstwy nie mają specjalnego celu, a dane zaczynają brakować, ponieważ zaprojektował niektóre komponenty bean, aby wykonać „usuwanie” z bazy danych. Baza kodu jest bardzo rozdęta i istnieją zadania tylko do synchronizacji danych, ponieważ baza danych nie jest znormalizowana. Jego podejście polegało na tworzeniu kopii zapasowych w celu przywrócenia brakujących danych i wydaje się, że nie wierzy w ponowne faktoring.

Po przedstawieniu PM swoich ustaleń architekt zostanie usunięty po zakończeniu umowy. Otrzymałem zadanie przebudowania tej aplikacji. Mój zespół składa się ze mnie i jednego młodszego programisty. Nie mamy żadnych innych zasobów. Otrzymaliśmy 6-miesięczne zamrożenie wymagań, w którym możemy skupić się na odbudowie tego systemu.

Zasugerowałem użycie systemu CMS, takiego jak Drupal, ale ze względów politycznych w organizacji klienta system musi być zbudowany od podstaw.

To pierwszy raz, kiedy będę projektować system o ponad 40 latach życia. Pracowałem tylko nad projektami o 3-5-letniej żywotności, więc ta sytuacja jest bardzo nowa, ale ekscytująca.

pytania

• Jakie względy projektowe sprawią, że system będzie bardziej „przyszłościowy”?
• Jakie pytania należy zadać klientowi / premierowi, aby system był bardziej „przyszłościowy”?

Dane są królem

Myślę, że nieco nierozsądnie jest oczekiwać, że aplikacja internetowa około 2013 roku będzie nadal działać i działać w 2053 roku. Technologie się zmienią. Platformy będą przychodzić i odchodzić. HTML może być wtedy osobliwą pamięcią. Ale twoje dane nadal będą dostępne.

Dane są więc twoim głównym celem. Dopóki Twoje dane będą nadal dostępne, ludzie będą mogli dostosować się do wszelkich nowych technologii. Upewnij się, że schematy danych są dobrze przemyślane i nadają się do rozbudowy. Nie spiesz się, określając je.

Jeśli chodzi o rzeczywiste aplikacje, Twoja firma prawdopodobnie ma rację, jeśli chodzi o dyrektywę „buduj od zera”. Prowadzę kilka ponad 10-letnich aplikacji internetowych i cieszę się, że nie są one powiązane z dominującymi systemami CMS z 2003 roku. Używają domowych, bardzo prostych ram. Myślę, że w przypadku czegoś takiego lepiej jest mieć bardzo podstawową strukturę, którą tworzysz specjalnie na potrzeby projektu.

Ale w rzeczywistości przez ponad 40 lat firma (miejmy nadzieję) będzie oferować sporo usług typu front-end i back-end, aby dostosować się do ewoluujących platform. Biorąc to pod uwagę, wybrałbym 5-10 lat życia dla indywidualnych aplikacji zorientowanych na użytkownika.

Produkujemy oprogramowanie, z którego korzystają klienci płacący od ponad 20 lat. Baza kodów przetrwała kilka generacji narzędzi kontroli źródła. Nasze oprogramowanie uderza we wszystkie punkty, z wyjątkiem tabletu.

Niektóre z tych problemów to esign i UETA . Nasi prawnicy uważają, że musimy zachować czytelność zapisów elektronicznych przez co najmniej 10 lat. W przypadku dokumentów, które są zachowane w całości, należy spojrzeć na PDF / A .

W przypadku bazy danych nie przejmuj się zbytnio normalizacją. Zamiast tego powinieneś martwić się rejestrowaniem wszystkiego i posiadaniem tabel audytu, które śledzą zmiany / usunięcia danych. Podczas aktualizacji wersji planuj równoległe testowanie nowych wersji, aby zapewnić migrację danych. Testowanie nowych wersji obejmuje także nowe systemy operacyjne - przez lata mieliśmy bardzo nieprzyjemne niespodzianki. Zachowaj nośniki instalacyjne i klucze licencyjne na wypadek konieczności wycofania. Testuj kopie zapasowe. Jeśli zamierzasz serializować obiekty do przechowywania w bazie danych, rób to jako XML zamiast serializacji dostarczanej przez środowisko programistyczne.

Dla twojego personelu bazy długoterminowe wymagają pamięci długoterminowej. Idealnie byłoby, gdyby ludzie byli w pobliżu od dawna. Jeśli jest to instytucjonalnie niemożliwe, musisz udokumentować wszystko w postaci wiki. A moja rada to wiki, która może połączyć się z twoim systemem śledzenia błędów.

W przypadku bazy kodu upewnij się, że masz komentarze w kodzie. Migracja z jednego systemu kontroli wersji do drugiego prawie zawsze spowoduje utratę komentarzy do odprawy. Jestem fanem testów nazw jednostek po specyfikacjach i numerach błędów. W ten sposób, jeśli test jednostkowy się Test_Bug_1235 zepsuje, wtedy wiesz, co i gdzie wyśledzić, co to ma być testowanie. Nie jest tak „seksowny” jak nazywanie testów, Check_File_Save_Networked_Drivesale tego rodzaju test trudno jest cofnąć do specyfikacji, wymagań lub błędów w przeciwieństwie do innych Test_requirement_54321_case_2.

Zamiast próbować dowiedzieć się, jak ta aplikacja będzie nadal działać za 20 lat, myślę, że powinieneś spędzić sześć miesięcy na rozwiązywaniu problemów, które odkrył pierwotny architekt, wdrożyć rozsądną, solidną architekturę i idź stamtąd

Częściowa dezormalizacja bazy danych niekoniecznie jest całkowicie nieoczekiwana w środowisku medycznym. Niektóre części medycznych baz danych mają cechy, które sprawiają, że dobrze pasują do modelu EAV (Entity / Attribute / Value) .

Odpowiedź z perspektywy front-end:

Nie słuchaj wszystkich, którzy mówią, że nie da się tego zrobić, ponieważ eksperymentalna usługa internetowa Uniwersytetu Stanowego w San Francisco, którą napisałem w 1996 roku, w końcu trafiła do nieba kilka lat temu i nigdy nie potrzebowała żadnej poprawki zgodności przeglądarki w tym czasie ; to prawie połowa twojego 40-letniego celu. A ten oparty na JavaScript interfejs, który stworzyłem w 1998 r. Dla projektu Stanford Research Institute, został zastąpiony czymś bardziej błyskotliwym kilka lat później, ale nie ma powodu, aby oryginalny interfejs użytkownika nadal nie działał dzisiaj z drobnymi poprawkami zgodności.

Sztuczka polega na tym, aby Twoja aplikacja korzystała wyłącznie z powszechnie obsługiwanych standardów W3C / ECMA i miała przejrzysty design pod Twoją kontrolą. Podczas gdy wiele aplikacji internetowych napisanych zgodnie z modną technologią z lat 90. nie działa dobrze lub w ogóle dzisiaj, aplikacje internetowe z lat 90. napisane zgodnie z głównymi standardami nadal działają. Mogą wyglądać passé, ale działają.

Celem nie jest napisanie aplikacji internetowej, która wejdzie na ich serwer i pozostanie tam przez 40 lat bez ponownego dotykania go. Ma zbudować fundament, który może być nadal używany przez dziesięciolecia, który może się rozwijać, aby obsługiwać nowe funkcje bez konieczności ponownej przebudowy.

Przede wszystkim musisz kodować do oficjalnych standardów i tylko do oficjalnych standardów. Żadna funkcja JavaScript nie jest częścią ratyfikowanego standardu ECMAScript; ES5.1 jest aktualną wersją i jest ogólnie obsługiwany, więc można ją bezpiecznie celować. Podobnie, obecne wersje HTML5, CSS i Unicode są dobre. Brak eksperymentalnych funkcji JavaScript, CSS3 lub HTML (tych z prefiksami dostawcy lub bez 100% zgodności między przeglądarkami). I żadnych specyficznych dla przeglądarki hacków. Możesz zacząć korzystać z nowej funkcji, gdy będzie w standardzie i wszyscy będą ją obsługiwać bez prefiksów.

Wsparcie dla ES5 oznaczałoby porzucenie IE8 lub wcześniejszej wersji, co i tak sugeruję, ponieważ wymaga specyficznych dla przeglądarki hacków, które będą bezużyteczne za kilka lat. Proponuję tryb ścisły ES5, aby uzyskać najlepszą szansę na długowieczność, która faktycznie ustawia podstawową kompatybilność przeglądarki w IE10 i najnowszych wersjach wszystkich innych . Przeglądarki te mają także natywną obsługę wielu funkcji sprawdzania poprawności formularzy HTML5 i funkcji symboli zastępczych, które będą przydatne przez bardzo długi czas.

Nowe wersje ECMAScript zachowują kompatybilność ze starszymi wersjami, więc o wiele łatwiej będzie przyjąć nadchodzące funkcje, jeśli kod zostanie napisany zgodnie z obowiązującymi standardami. Na przykład klasy zdefiniowane przy użyciu nadchodzącej classskładni będą w pełni zamienne z klasami zdefiniowanymi przy użyciu bieżącej constructor.prototypeskładni. W ciągu pięciu lat programista może przepisać klasy do formatu ES6 na zasadzie plik po pliku, nie niszcząc niczego - zakładając oczywiście, że masz również dobre testy jednostkowe.

Po drugie, unikaj modnych ram aplikacji JavaScript, zwłaszcza jeśli zmieniają sposób kodowania aplikacji. Kręgosłup był wściekły, potem SproutCore i Ember, a teraz Angular jest ramą, którą wszyscy uwielbiają promować. Mogą być przydatne, ale mają też coś wspólnego: często psują aplikacje i wymagają zmian kodu, gdy pojawiają się nowe wersje, a ich długowieczność jest wątpliwa. Niedawno zaktualizowałem aplikację Angular 1.1 do wersji 1.2 i sporo trzeba było przepisać. Podobnie przejście z Backbone 2 do 3 wymaga wielu zmian HTML. Powodem są powolne standardy, ale ramy te poruszają się szybko, a koszty okresowego łamania są kosztem.

Ponadto nowe oficjalne standardy często pozostawiają stare ramy przestarzałe, a kiedy to się dzieje, te ramy albo mutują (z przełomowymi zmianami), albo zostają w tyle. Wiesz, co stanie się ze wszystkimi konkurencyjnymi bibliotekami obietnic na świecie po ratyfikacji ECMAScript 6 i wszystkich przeglądarek obsługujących standardową klasę Promise? Staną się przestarzałe, a ich twórcy przestaną je aktualizować. Jeśli wybierzesz odpowiednią strukturę, kod może się wystarczająco dobrze dostosować, a jeśli źle zgadniesz, przyjrzysz się poważnemu refaktoryzacji.

Więc jeśli zastanawiasz się nad zastosowaniem biblioteki lub frameworku innej firmy, zadaj sobie pytanie, jak trudno będzie ją usunąć w przyszłości. Jeśli jest to framework taki jak Angular, którego nigdy nie można usunąć bez przebudowania aplikacji od zera, to dobry znak, że nie można go użyć w 40-letniej architekturze. Jeśli jest to widget kalendarza innej firmy, który został wyodrębniony za pomocą niestandardowego oprogramowania pośredniego, jego wymiana zajmie kilka godzin.

Po trzecie, nadaj mu dobrą, czystą strukturę aplikacji. Nawet jeśli nie używasz frameworka aplikacji, możesz nadal korzystać z narzędzi programistycznych, budować skrypty i dobry, czysty projekt. Osobiście jestem fanem zarządzania zależnościami Closure Toolkit, ponieważ jest on lekki, a jego koszty ogólne są całkowicie usuwane po zbudowaniu aplikacji. LessCSS i SCSS są również świetnymi narzędziami do organizowania arkuszy stylów i tworzenia opartych na standardach arkuszy stylów CSS do wydania.

Możesz także zorganizować własny kod w klasy jednorazowego użytku o strukturze MVC. To znacznie ułatwi powrót do przyszłości za kilka lat i zrozumienie, o czym myślałeś, kiedy coś napisałeś, i zastąpienie tylko tych części, które tego potrzebują.

Powinieneś także postępować zgodnie z radami W3C i całkowicie ukryć informacje prezentacyjne w swoim HTML. (Obejmuje to kody, takie jak nadawanie elementom nazw klas prezentacyjnych, takich jak „duży zielony tekst” i „szerokość dwóch kolumn”.) Jeśli Twój HTML jest semantyczny, a CSS jest prezentacyjny, o wiele łatwiej będzie go utrzymać i dostosować na nowe platformy w przyszłości. Łatwiej będzie także dodać obsługę specjalistycznych przeglądarek dla osób niewidomych lub niepełnosprawnych.

Po czwarte, zautomatyzuj swoje testy i upewnij się, że masz prawie pełny zasięg. Napisz testy jednostkowe dla każdej klasy, po stronie serwera lub w JavaScript. Na froncie upewnij się, że każda klasa działa zgodnie ze specyfikacją we wszystkich obsługiwanych przeglądarkach. Zautomatyzuj te testy z bota kompilacji dla każdego zatwierdzenia. Jest to ważne zarówno dla długowieczności, jak i niezawodności, ponieważ można wcześnie wykryć błędy, nawet jeśli obecne przeglądarki je zasłaniają. Zarówno frameworki testowe oparte na JSUnit Jasmine, jak i Google Closure są dobre.

Będziesz także chciał przeprowadzić pełne testy funkcjonalne interfejsu użytkownika, w których Selenium / WebDriver są dobre. Zasadniczo piszesz program, który przechodzi przez interfejs użytkownika i używa go tak, jakby ktoś go testował. Połącz je również z robotem budowlanym.

Wreszcie, jak wspomnieli inni, twoje dane są najważniejsze. Zastanów się nad modelem przechowywania danych i upewnij się, że jest on trwały. Upewnij się, że twój schemat danych jest solidny, i upewnij się, że został dokładnie przetestowany przy każdym zatwierdzeniu. I upewnij się, że architektura twojego serwera jest skalowalna. Jest to nawet ważniejsze niż cokolwiek, co robisz w interfejsie.

Pomijając kwestię nieuzasadnionych oczekiwań klienta i koncentrując się na kwestiach projektowych, nie posunęłbym się nawet do 40 lat, ale wydaje się, że problemem, który wydaje się mieć w przypadku długoterminowej ewolucji, jest właśnie to, dla czego stworzono REST . Rozumiem przez to REST jako styl architektury, a nie rozwój oparty na modnych słowach, który jest tak często kojarzony z tym terminem w dzisiejszych czasach.

Do pewnego stopnia ludzie mylą się z REST, ponieważ w mojej rozprawie nie zawarłem wystarczająco dużo szczegółów na temat projektowania typów mediów. To dlatego, że zabrakło mi czasu, a nie dlatego, że myślałem, że było to mniej ważne niż inne aspekty REST. Podejrzewam, że wiele osób myli się, ponieważ czytają tylko wpis Wikipedii na ten temat, który nie jest oparty na wiarygodnych źródłach.

Myślę jednak, że większość ludzi popełnia błąd, że projektowanie prostych rzeczy powinno być proste. W rzeczywistości wysiłek wymagany do zaprojektowania czegoś jest odwrotnie proporcjonalny do prostoty wyniku. W miarę upływu stylów architektonicznych REST jest bardzo prosty.

REST to projektowanie oprogramowania na skalę dziesięcioleci : każdy szczegół ma na celu promowanie długowieczności oprogramowania i niezależnej ewolucji.

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

Wspomniałeś, że zamierzasz użyć interfejsu RESTful. Ten komentarz sam w sobie sugeruje, że powinieneś przeprowadzić poważne badania w tym zakresie i spróbować zrozumieć, na czym naprawdę polega REST. Prawdopodobnie kojarzysz to jedynie z mapowaniem metod HTTP na operacje CRUD, które większość ludzi uważa za REST, ale nie ma to z tym nic wspólnego.

Pomyśl o REST jako o formalizacji architektury samej sieci. W ten czy inny sposób istnieje wiele części sieci napisanych dziesięć lat temu lub więcej, które są nadal dostępne i mogą być używane z klientem wykonanym dzisiaj, więc mamy coś w tym dziale. Zapewniam, że będzie to dużo pracy, ponieważ prawidłowe wykonanie REST jest trudne, ale długoterminowe korzyści są tego warte.

Po przeczytaniu pytania i innych (bardzo dobrze przemyślanych) odpowiedzi pomyślałem, że zostawię również dwa centy. Uwaga: w ogóle nie muszę utrzymywać żadnej starej aplikacji / oprogramowania. Jako odniesienie używam mojej własnej aplikacji hobby, która pobiera niektóre otwarte dane rządowe, analizuje i wyświetla je w różnych formatach. Aplikacja zaczęła się jako projekt, w którym nie byłem sam i gov właśnie ogłosił , że w jakiś sposób zaoferuje te dane. Było więc jasne, że z czasem wiele rzeczy się zmieni. I zrobili. Czego się nauczyłem z tego:

• Podziel rzeczy na małe aplikacje. Każdy jest w stanie samodzielnie wykonać swoje zadanie. To sprawia, że ​​wymiana jednego elementu jest bardzo szybka, bardzo bezpieczna i bardzo łatwa. A kiedy musisz wrócić, nietrudno jest zrozumieć, dlaczego coś się dzieje i jak się dzieje. Jeśli Ty lub ktoś inny będziesz musiał później coś zmienić, łatwiej będzie wymienić jedną część niż cały zestaw rzeczy.
• Uzyskaj solidne stałe oprogramowanie pośrednie / warstwę, która jest używana do komunikacji między różnymi częściami. W tym przypadku użyłem JSON, ale XML, ini lub podobne standardy również byłyby w porządku. Jest łatwy do powtórzenia i może zostać przekształcony w prawie wszystko. Wszystkie są sprawdzonymi standardami, które przetrwają dość długo. Nawet jeśli podstawowe dane i / lub model przechowywania ulegną zmianie. Każda z aplikacji może używać własnego magazynu danych do określonego zadania. Dzięki temu ilość zeskanowanych danych dla zadania jest mniejsza, a zatem łatwiejsza w obsłudze i konserwacji oraz łatwiejsza do wymiany.
• Nie martw się o decyzje dotyczące języka programowania. Z czasem się zmienią. Upewnij się tylko, że używasz języka, w którym czujesz się komfortowo lub który najlepiej pasuje do zadania.
• Upewnij się, że twoje miejsce do przechowywania danych jest „skalowalne w poziomie” i że łatwo jest podłączyć dodatkowe moduły pamięci.
• Uzyskaj wspólny punkt (w moim przypadku są to identyfikatory URI), w którym wywoływane są mini-aplikacje i / lub wymieniaj dane.

Podsumowując: Najważniejsze jest dla mnie rozdzielenie problemów i możliwość wymiany części przeznaczonych do zadań. Po prostu wiesz, że za 40 lat (nawet za 5 lub 10) sprzęt, interfejsy, pamięć itp. Bardzo się zmienią. Później programiści będą musieli zareagować na te zmiany i wymienić części aplikacji, czy to kontener danych, czy części interfejsu użytkownika.

Aby wszystko było jak najbardziej „przyszłościowe”, zaplanuj zmiany. Oznacza to, że staraj się nie optymalizować niczego innego niż możliwość łatwej zmiany. Więc nie ma normalizacji, nie ma ścisłej walidacji, i luźne sprzężenie.

• Korzystaj z głównych technologii open source. W przypadku danych systemy o zamkniętym źródle są głównym źródłem ryzyka, ponieważ nie można zaplanować, które firmy pójdą za nimi lub zmienią strategie, zabierając ze sobą cały dostęp do danych. Również drobne projekty typu open source bez aktywnej społeczności są bardziej narażone na utratę wsparcia.

• Użyj bazy danych NoSQL bez schematu. Rodzaje wykorzystywanych nieustrukturyzowanych danych są niemalże wprost z podręcznika dla magazynu dokumentów takiego jak MongoDB. Tradycyjne relacyjne bazy danych i ich normalizacja są dobre, gdy wiesz, jak będą tworzone dane, ale to naprawdę fikcja, szczególnie tutaj. Koszty zmiany schematu w RDBS stają się coraz większe wraz z rozwojem systemu. Wiedz, że jakakolwiek struktura zostanie teraz wybrana, ostatecznie się zmieni.

• Oddziel system mocno, stosując powszechnie akceptowane standardy. Podział dostępu do danych i mutacji na usługi sieciowe jest krokiem w tym kierunku. Połączenie tego z kolejkami komunikatów służącymi do przesyłania zmian i tym samym pomoże poszczególnym częściom systemu zmieniać języki lub technologie z czasem.

OK, więc powiem tutaj kilka rzeczy, które prawdopodobnie będą dość niepopularne, ale trzymajcie się mnie.

Ponieważ jest to twój pierwszy projekt, w którym dane i / lub aplikacja mają trwać ponad 20 lat, a ty prowadzisz projekt, musisz cofnąć się o krok i pomyśleć o tym, jakie są szanse powodzenia tego projektu . Ponieważ są one zasadniczo zerowe.

Musisz poświęcić ogromną ilość czasu na skupienie się na projekcie bazy danych i poprawieniu tego. Aby ten projekt się powiódł, musisz wprowadzić do niego architekta danych, a wcześniej to później. Bez kogoś, kto ma doświadczenie w projektowaniu baz danych i który jest dobrze wyćwiczony w oczekiwaniu na to, jak dane mogą być wykorzystane w przyszłości, szanse na to, że dane będą nadal przydatne po 5 latach, a mniej niż 40 latach, są niewielkie.

Oczekiwanie, że dwie osoby (z których jedna ma tytuł jr. Dev), zbudują coś od zera, co prawdopodobnie potrwa 40 lat, prawdopodobnie nie odniesie sukcesu. Powinien istnieć zespół ludzi, którzy mają duże doświadczenie w pracy z dużymi projektami takimi jak ten, którzy pracują nad projektowaniem danych, projektowaniem API i projektowaniem aplikacji. Coś takiego nie jest projektem dla 2 osób.

Chęć powiązania projektu z czymś takim jak Drupal pokazuje, dlaczego projekt potrzebuje ludzi, którzy są przyzwyczajeni do pracy nad tego rodzaju projektami. Nie chcesz wiązać aplikacji z niczym, co może przestać być modne w ciągu kilku lat. Jeśli tak, znalezienie kogoś do pracy nad systemem za 5-10 lat może bardzo szybko stać się bardzo trudne.

Poradziłbym tę radę kierownictwu i wyjaśniłbym im, że potrzebujesz więcej starszych osób do projektu. W przeciwnym razie projekt jest skazany na niepowodzenie i prawdopodobnie skończysz za niego.

Aplikacja nie musi przetrwać 40 lat bez żadnej ewolucji. Ponieważ jednak byłby lub powinien zostać zbudowany od podstaw, mógłby nadal „funkcjonować”.

Najważniejszą rzeczą jest „architektura danych”, która pozwala na pewną stabilność i zarządzanie, a także na rozszerzalność.

Zaprojektowaliśmy architekturę danych i taksonomię, które mogą prawie przetrwać koniec ludzkości, ale nadal mogą być rozszerzalne. Znalazłeś prawdziwą osobę DATA TAXONOMY / DATA ARCHITECTURE, która zrobi to za Ciebie.

Kluczem tutaj jest skupienie się na bazie danych (jak powiedziano kilka powyżej). Musi to być spójne i całkowicie opisywać operację. Musi rosnąć wraz z operacją, gdy się zmienia. Jeśli zmiana nie będzie łatwa, to przestanie być aktualna i będzie to pocałunek śmierci. Reszta jest stosunkowo mniej ważna.

Nie zgadzam się z tymi powyżej, którzy sugerują, że normalizacja nie jest ważna, chociaż zawsze są przypadki, w których obecne systemy nie są w stanie sprostać zadaniu. W takich przypadkach denormalizuj, ale upewnij się, że baza danych obsługuje dodatkowe zapisy / zmiany w ramach transakcji atomowej. W ten sposób możesz skutecznie zignorować problem, dopóki go nie naprawisz.

Firma, w której pracowałem przed przejściem na emeryturę, prowadzi system, który został napisany od zera i rozwija się prawie nieprzerwanie od 25 lat i obejmuje praktycznie wszystkie aspekty średniego detalisty. Ważnymi aspektami tego systemu są:

• Integracja jest niezbędna.
• Baza danych musi być tak samo poprawna i zrozumiała zarówno dla informatyków, jak i innych pracowników, dlatego wymagany jest niemal paranoiczny nacisk na nazewnictwo. Mamy tabele zdefiniowanych mnemoników, które są następnie łączone w celu utworzenia nazw tabel i pól, a wszystkie „kody” zostały również nazwane jako stałe i zapisane w strukturze tabel EAV.
• Osadziliśmy logikę biznesową w wyzwalaczach baz danych. Na początku jest to bolesne i wymaga dodatkowej pracy w celu przesłania komunikatów o błędach do klientów i umożliwienia elastycznej zmiany wyzwalaczy bez blokowania całej tabeli w niektórych systemach, ale szybko staje się to ogromną oszczędnością czasu i wymusza poprawność bazy danych niż inaczej.
• Załóżmy, że będziesz przechowywać przynajmniej tabele referencyjne (najlepiej wszystkie oprócz najszybszych i najmniej ważnych transakcji) przez cały okres eksploatacji systemu, nawet po „usunięciu”, aby Twoje referencje były prawidłowe.
• Ze względu na powyższe upewnij się, że wszelkie unikalne identyfikatory i numery transakcji mają długi rozmiar. (Początkowo żartem zasugerowałem, że muszą trwać, dopóki nie przejdę na emeryturę).

Sugerowałbym użycie pozyskiwania zdarzeń oraz segregacji odpowiedzialności za polecenia i zapytania . Wynika to głównie z tego, że jedyne, co możesz być pewien, to wydarzenia, które już się pojawiły. Mogą pojawić się nowe typy wydarzeń. Więc nawet jeśli zastanowisz się nad modelem, na pewno stanie się on przestarzały. Migracja wszystkich danych w każdej wersji może być niewykonalna. Dlatego najlepiej jest mieć model, który odpowiada Twoim bieżącym potrzebom i który jest obliczany na podstawie już zarejestrowanych zdarzeń za każdym razem, gdy go potrzebujesz, a następnie wydać zdarzenia, które są obliczane na podstawie aktualnego stanu tego modelu.

Pamiętaj też o testowaniu. Jeśli aplikacja będzie używana za dziesięć lat, testerzy muszą upewnić się, że nadal działa tak, jak powinna. Spraw, by testowanie aplikacji było jak najłatwiejsze.