Czy usługą jest udostępnianie bazy danych w architekturze SOA?

Niedawno czytam Wzorce integracji przedsiębiorstw Hohpe i Woolf, niektóre książki Thomasa Erla na temat SOA oraz oglądam różne filmy i podcasty Udi Dahana i in. w systemach CQRS i systemach sterowanych zdarzeniami.

Systemy w moim miejscu pracy cierpią z powodu wysokiego sprzężenia. Chociaż teoretycznie każdy system ma własną bazę danych, istnieje wiele połączeń między nimi. W praktyce oznacza to, że istnieje jedna ogromna baza danych, z której korzystają wszystkie systemy. Na przykład istnieje jedna tabela danych klienta.

Wiele z tego, co przeczytałem, zdaje się sugerować denormalizację danych, tak aby każdy system korzystał tylko ze swojej bazy danych, a wszelkie aktualizacje jednego systemu były propagowane do wszystkich innych za pomocą przesyłania komunikatów.

Myślałem, że to jeden ze sposobów egzekwowania granic w SOA - każda usługa powinna mieć własną bazę danych, ale potem przeczytałem:

/programming/4019902/soa-joining-data-across-multiple-services

i sugeruje, że jest to niewłaściwa rzecz.

Segregacja baz danych wydaje się dobrym sposobem na oddzielenie systemów, ale teraz jestem trochę zdezorientowany. Czy to dobra droga? Czy kiedykolwiek zaleca się segregowanie bazy danych, na przykład usługi SOA, kontekstu DDD Bounded, aplikacji itp.?

Oddzielenie działa tylko wtedy, gdy naprawdę istnieje separacja. Zastanów się, czy masz system zamówień:

• Tabela: KLIENT
• Tabela: ZAMÓWIENIE

Jeśli to wszystko, co masz, nie ma powodu, aby je rozdzielić. Z drugiej strony, jeśli masz to:

• Tabela: KLIENT
• Tabela: ZAMÓWIENIE
• Tabela: CUSTOMER_NEWSLETTER

Następnie możesz argumentować, że ORDER i CUSTOMER_NEWSLETTER są częścią dwóch całkowicie oddzielnych modułów (zamówienia i marketing). Być może sensowne jest przeniesienie ich do osobnych baz danych (po jednej dla każdej tabeli) i umożliwienie obu modułom wspólnego dostępu do wspólnej tabeli KLIENTA we własnej bazie danych.

W ten sposób upraszczasz każdy moduł, ale zwiększasz złożoność warstwy danych. W miarę jak Twoja aplikacja staje się coraz większa, widzę zaletę oddzielania. Będzie coraz więcej „wysp danych”, które tak naprawdę nie będą ze sobą powiązane. Jednak zawsze będą jakieś dane, które przecinają wszystkie moduły.

Decyzja o umieszczeniu ich w różnych fizycznych bazach danych zwykle opierałaby się na ograniczeniach w świecie rzeczywistym, takich jak częstotliwość tworzenia kopii zapasowych, ograniczenia bezpieczeństwa, replikacja w różnych lokalizacjach geograficznych itp. Nie dzieliłbym tabel na różne fizyczne bazy danych tylko ze względu na oddzielne obawy. Można to uprościć za pomocą różnych schematów lub widoków.

Tam, gdzie pracuję, mamy ESBz którymi połączonych jest 6 różnych aplikacji (lub powinienem powiedzieć „punkty końcowe”). Te 6 aplikacji działa z 3 różnymi schematami Oracle w 2 instancjach bazy danych. Niektóre z tych aplikacji współistnieją w tym samym schemacie nie dlatego, że są ze sobą powiązane, ale ponieważ nasza infrastruktura bazy danych jest zarządzana przez zewnętrznego dostawcę, a uzyskanie nowego schematu trwa wiecznie (nie mamy oczywiście dostępu do DBA) ... naprawdę trwa tak długo, że w pewnym momencie pomyśleliśmy o ponownym użyciu istniejącego schematu „tymczasowo”, aby móc kontynuować rozwój. Aby wymusić „separację” danych, nazwy tabel mają prefiks, na przykład „CST_” dla klienta. Musimy też pracować ze schematem, którego z ważnych powodów nie możemy całkowicie zmienić ... To dziwne, wiem. Oczywiście, jak to zawsze bywa, „tymczasowo”

Nasze różne aplikacje łączą się ze swoimi odpowiednimi schematami baz danych i pracują z własnymi pakietami PL / SQL i absolutnie zabraniamy sobie bezpośredniej interakcji z tabelami / danymi, które znajdują się poza naszą domeną aplikacji.

Gdy jedna z aplikacji podłączonych do ESB potrzebuje informacji poza swoją domeną, wywołuje powiązaną usługę w ESB w celu uzyskania danych, nawet jeśli informacje te są w rzeczywistości w tym samym schemacie, wymagając teoretycznie tylko małej instrukcji dołączenia w jedno z zapytań SQL .

Robimy to, aby móc podzielić naszą domenę aplikacji na różne schematy / bazy danych, a także aby usługi w ESB nadal działały poprawnie, gdy to się stanie (wkrótce będą święta Bożego Narodzenia, korsujemy palce)

Teraz może to wyglądać dziwnie i okropnie z zewnątrz, ale są ku temu powody i chciałem tylko podzielić się tym konkretnym doświadczeniem, aby pokazać, że co najmniej jedna baza danych nie jest tak ważna. Czekaj, tak jest! , z wielu powodów (+1 dla Scotta Whitlocka, patrz ostatni akapit na temat tworzenia kopii zapasowych i takich, które mya wprowadzają cię w kłopoty) Ale równie ważne jest, aby mieć pewność, że twoje usługi SOA są odpowiednio zaprojektowane, przynajmniej taka jest moja opinia, i ja nie jestem DBA. Ostatecznie wszystkie twoje bazy danych należą do „magazynu danych przedsiębiorstwa”, prawda?

Wreszcie, nie zmienię ostatniego akapitu Scotta Whitlocka, szczególnie tego

Nie dzieliłbym tabel na różne fizyczne bazy danych tylko ze względu na problemy.

jest naprawdę bardzo ważne. Nie rób tego, jeśli nie ma powodu.

Widziałem najgorsze możliwe koszmary w architekturze oprogramowania ze względu na integrację danych, a najlepszą bronią przeciwko tego rodzaju bałaganowi, jaki do tej pory napotkałem, są powiązane z kontekstem DDD. W pewnym sensie nie jest to bardzo dalekie od „SOA zrobione dobrze”.

Jednak same dane nie są najlepszym sposobem na zaatakowanie problemu. Należy skoncentrować się na oczekiwanym / potrzebnym zachowaniu i zabrać dane tam, gdzie jest to ważne. W ten sposób możemy mieć pewne powielanie, ale nie jest to zwykle problem w porównaniu z blokami ewolucji systemu, prawie zawsze związanymi z architekturami zintegrowanymi z danymi.

Mówiąc najprościej: jeśli szukasz luźno powiązanych systemów, nie pozostań w związku z danymi. Wybierz systemy zamknięte weel i dobrze ustrukturyzowany kanał komunikacji pomiędzy nimi, działający jako „lingua franca”.

Oddzielenie baz danych i utrzymanie spójności danych między nimi to zadanie na poziomie eksperckim. Bardzo łatwo jest się pomylić i skończyć z problemami z duplikatami itp., Których obecny system ma na celu uniknąć. Szczerze mówiąc, wzięcie działającego systemu i zrobienie tego jest właściwie gwarancją wprowadzenia nowych błędów, które nie przynoszą prawdziwej wartości użytkownikom.

Prawidłowe rozdzielenie problemów biznesowych na różne bazy danych (lub przynajmniej różne schematy) jest zaletą .

Proszę zobaczyć opis wzoru CQRS autorstwa Martina Fowlera :

Gdy nasze potrzeby stają się coraz bardziej wyrafinowane, stopniowo odchodzimy od [traktowania systemu informatycznego jak magazynu danych CRUD] ... Zmiana wprowadzona przez CQRS polega na podzieleniu tego modelu koncepcyjnego na osobne modele do aktualizacji i wyświetlania ... Jest miejsce na znaczne różnice tutaj. Modele w pamięci mogą współużytkować tę samą bazę danych, w którym to przypadku baza danych działa jako komunikacja między dwoma modelami.Mogą jednak również korzystać z oddzielnych baz danych , skutecznie tworząc bazę danych po stronie zapytania przez ReportingDatabase w czasie rzeczywistym. W takim przypadku musi istnieć jakiś mechanizm komunikacji między dwoma modelami lub ich bazami danych.

I zasady architektoniczne NServiceBus :

Rozdzielanie zapytań poleceń

Rozwiązanie, które pozwala uniknąć tego problemu, oddziela polecenia i zapytania na poziomie systemu, nawet powyżej poziomu klienta i serwera. W tym rozwiązaniu są dwie „usługi”, które obejmują zarówno klienta, jak i serwer - jedną odpowiedzialną za polecenia (tworzenie, aktualizację, usuwanie), a drugą za zapytania (czytanie). Usługi te komunikują się tylko za pośrednictwem wiadomości - jedna nie ma dostępu do bazy danych drugiej ...

I Command Query Responsibility podziału (CQRS)

Segregacja odpowiedzialności za polecenia i zapytania

Większość aplikacji czyta dane częściej niż je zapisuje. Na podstawie tego stwierdzenia dobrym pomysłem byłoby stworzenie rozwiązania, w którym z łatwością można dodać więcej baz danych do odczytu, prawda? A co, jeśli stworzymy bazę danych przeznaczoną tylko do czytania? Nawet lepiej; co jeśli zaprojektujemy bazę danych w taki sposób, aby szybciej z niej czytać? Jeśli projektujesz swoje aplikacje w oparciu o wzorce opisane w architekturze CQRS, będziesz mieć skalowalne i szybkie w odczycie dane.