È una cattiva pratica per i servizi condividere un database in SOA?

Il disaccoppiamento funziona solo se c'è davvero separazione. Considera se hai un sistema di ordinazione:

• Tabella: CLIENTE
• Tabella: ORDINE

Se è tutto ciò che hai, non c'è motivo di disaccoppiarli. D'altra parte, se hai questo:

• Tabella: CLIENTE
• Tabella: ORDINE
• Tabella: CUSTOMER_NEWSLETTER

Quindi potresti obiettare che ORDER e CUSTOMER_NEWSLETTER fanno parte di due moduli completamente separati (ordine e marketing). Forse ha senso spostarli in database separati (uno per ogni tabella) e avere entrambi i moduli per condividere l'accesso alla tabella CUSTOMER comune nel proprio database.

In questo modo stai semplificando ogni modulo, ma aumenti la complessità del tuo livello dati. Man mano che la tua applicazione diventa sempre più grande, posso vedere un vantaggio nel separare. Ci saranno sempre più "isole di dati" che non hanno alcuna relazione tra loro. Tuttavia, ci saranno sempre dei dati che taglia trasversalmente tutti i moduli.

La decisione di inserirli in diversi database fisici sarebbe in genere basata su vincoli reali come la frequenza dei backup, le restrizioni di sicurezza, la replica in diverse posizioni geografiche, ecc. Non vorrei separare le tabelle in database fisici diversi solo a causa di separare le preoccupazioni. Questo può essere gestito più semplicemente con diversi schemi o viste.

Dove lavoro abbiamo un ESB a cui sono collegate 6 diverse applicazioni (o dovrei dire "endpoint") . Queste 6 applicazioni funzionano con 3 diversi schemi Oracle su 2 istanze di database. Alcune di queste applicazioni coesistono nello stesso schema non perché sono correlate ma perché la nostra infrastruttura di database è gestita da un fornitore esterno e ottenere un nuovo schema richiede solo per sempre (inoltre, non abbiamo accesso DBA ovviamente) ... ci vuole davvero tanto tempo che a un certo punto abbiamo pensato di riutilizzare uno schema esistente "temporaneamente" per poter continuare lo sviluppo. Per applicare la "separazione" dei dati, i nomi delle tabelle sono prefissati, ad esempio "CST_" per il cliente. Inoltre, dobbiamo lavorare con uno schema che, per alcune valide ragioni, non possiamo assolutamente cambiare ... È strano, lo so. Naturalmente, come sempre accade, "temporaneamente" è cambiato in "temporar-namently" se sai cosa intendo; -)

Le nostre diverse applicazioni si collegano ai loro rispettivi schemi di database e lavorano con i loro pacchetti PL / SQL e ci vietiamo assolutamente di interagire direttamente con tabelle / dati che si trovano al di fuori del nostro dominio dell'applicazione.

Quando una delle applicazioni connesse all'ESB necessita di informazioni esterne al suo dominio, chiama il servizio correlato sull'ESB per ottenere i dati, anche se tali informazioni sono in effetti nello stesso schema, richiedendo in teoria solo una piccola dichiarazione di join in una delle richieste SQL .

Lo facciamo per poter suddividere il nostro dominio applicativo in diversi schemi / database, e per fare in modo che i servizi dell'ESB funzionino ancora correttamente quando succede (è Natale a breve, stiamo incessantemente le dita)

Ora, questo può sembrare strano e terribile dall'esterno, ma ci sono delle ragioni e volevo solo condividere questa esperienza concreta per mostrarti che uno o più database non è così importante. Aspetta, lo è! , per molte ragioni (+1 per Scott Whitlock, vedi l'ultimo paragrafo sul backup e in modo tale che ti porti nei guai) Ma è altrettanto importante pensare che i tuoi servizi SOA siano correttamente progettato, almeno questa è la mia opinione, e io non sono un DBA. In definitiva, tutti i database appartengono al "datawarehouse aziendale", giusto?

Infine, non riformulerò l'ultimo paragrafo di Scott Whitlock, in particolare questo

I wouldn't separate tables into different physical databases just because of separating concerns.

è davvero super importante. Non farlo se non c'è motivo.

Ho visto i peggiori incubi possibili nell'architettura del software a causa dell'integrazione dei dati e la migliore arma contro questo tipo di disordine che ho incontrato finora Contesti delimitati in stile DDD. Il che non è molto lontano da "SOA fatto bene", in un certo senso.

Tuttavia, i dati stessi non sono il modo migliore per attaccare il problema. Uno dovrebbe concentrarsi sul comportamento previsto / necessario e portare i dati dove è importante. Potremmo finire per avere qualche duplicazione in questo modo, ma questo non è normalmente un problema rispetto ai blocchi per l'evoluzione del sistema quasi sempre associati a architetture integrate nei dati.

Per dirla in modo semplice: se stai cercando sistemi con accoppiamento lento, non rimanere accoppiato sui dati. Vai per sistemi incapsulati weel e un canale di comunicazione ben strutturato in mezzo, agendo come "lingua franca".

Disaccoppiare i database e mantenere i dati coerenti tra loro è un compito di livello esperto. È molto facile sbagliare e finire con i problemi dei duplicati, ecc, che il sistema attuale è progettato per evitare. Francamente, prendere un sistema funzionante e farlo è più o meno la garanzia di introdurre nuovi bug privi di valore reale per gli utenti.

Se fatto correttamente, separando le preoccupazioni di business in diversi database (o almeno schemi diversi) è una virtù .

Consulta la descrizione di Martin Fowler del pattern CQRS :

As our needs become more sophisticated we steadily move away from [treating an information system like a CRUD datastore]... The change that CQRS introduces is to split that conceptual model into separate models for update and display... There's room for considerable variation here. The in-memory models may share the same database, in which case the database acts as the communication between the two models. However they may also use separate databases, effectively making the query-side's database by a real-time ReportingDatabase. In this case there needs to be some communication mechanism between the two models or their databases.

E Principi architettonici di NServiceBus :

Command Query Separation

A solution that avoids this problem separates commands and queries at the system-level, even above that of client and server. In this solution there are two "services" that span both client and server - one in charge of commands (create, update, delete), the other in charge of queries (read). These services communicate only via messages - one cannot access the database of the other...

E Comando e Query Responsibility Segregation (CQRS)

Command and Query Responsibility Segregation

Most applications reads data more frequently than they write data. Based on that statement, it would be a good idea to make a solution where easily you can add more databases to read from, right? So what if we set up a database dedicated just for reading? Even better; what if we design the database in a way so it’s faster to read from it? If you design your applications based on the patterns described in CQRS architecture, you will have a solution that is scalable and fast at reading data.