Pattern di architettura microkernel e applicabilità per applicazioni aziendali

Question

Pattern di architettura microkernel e applicabilità per applicazioni aziendali

#1 da (2 voti)

4

Siamo nel business della costruzione di applicazioni web personalizzabili. Abbiamo il team principale che fornisce quella che noi chiamiamo la core piattaforma (fornisce servizi come sicurezza, fatturazione, ecc.) In aggiunta ai quali core prodotti sono costruiti. Questi prodotti principali sono soluzioni specifiche del settore come telecomunicazioni, servizi di utilità, ecc. Questi prodotti principali vengono in seguito utilizzati da altri team per creare soluzioni specifiche del cliente in un determinato settore.

Fino ad ora abbiamo una separazione netta tra piattaforma e prodotto principale. Le soluzioni specifiche del cliente sono realizzate personalizzando il 20-40% dell'offerta principale e il re-packaging. La piattaforma principale e i prodotti principali vengono rilasciati insieme come app monolitiche (ear).

Sto cercando di migliorare la situazione attuale in modo che ci sia una separazione più pulita su questi 3. Ciò ci consente di evolvere ciascuno di questi 3 separatamente ecc.

Ho letto l'architettura Microkernel e ho sentito che posso prendere e applicare i principi nel mio contesto. Ma la maggior parte della mia lettura di questo modello è sempre nel contesto di sistemi operativi o server applicativi, ecc. Mi chiedo se ci siano degli esempi su come quel modello è stato usato per architettare applicazioni aziendali. Oppure potresti fornire alcune informazioni su come applicare quel modello al mio problema.

architecture design-patterns architectural-patterns

posta Aravind R. Yarram 09.11.2012 - 01:11

fonte

1 risposta

Leggi altre domande sui tag architecture design-patterns architectural-patterns

Nella scelta di un framework di architettura orientato ai servizi che deve lavorare con .NET e con Java, cosa cercare? Come implementare lo zucchero di sintassi in OO

score 2 · Answer 1

Questo è uno schema "Modulo", così come un modello "Persone" - il tuo codice può sembrare diverso ma non è lì che giace la carne della differenza. Penso che tu capisca a quale modello viene data la situazione a cui stai tentando di applicarlo.

In realtà l'applicazione sarebbe simile alla seguente:

Supponi che la piattaforma principale sia il livello più basso nel tuo "stack".

Nel codice, questi tre livelli si trovano in pacchetti diversi, che probabilmente hai già. Rendi certo che nessun livello sottostante faccia riferimento o abbia dipendenza da qualcosa nei livelli precedenti. Ciò proteggerà la tua piattaforma dalle complessità dei tuoi prodotti e delle cose specifiche del cliente. Crea alcune serie di facciate e altre semplici astrazioni tra qualsiasi livello e quelle sottostanti. Ad esempio, la mia facciata a un modulo di database nella piattaforma principale può essere costituita da una factory che genererà un'istanza che aderisce a un'interfaccia "DataSource", a differenza di qualcuno sul team del prodotto principale che raggiunge direttamente la piattaforma principale (non attraverso la facciata) e invece di istanziare concretamente un SQLDatabaseSource. Questo proteggerà i tuoi livelli di Prodotto e Cliente dalle modifiche all'implementazione della tua Piattaforma.

In secondo luogo, i team devono essere strutturati per comunicare efficacemente in un modo concettualmente corrispondente a questo approccio "downstream". Il team della piattaforma deve mostrare interesse per le funzionalità di cui i team di prodotto hanno più bisogno, documentare in modo pulito come utilizzarle e progettarle in modo pulito in modo che il team del cliente non debba accoppiarsi strettamente con la loro implementazione. Devono anche chiarire i modi in cui non vogliono o non sono in grado di accogliere le squadre a valle. Forse avranno i cicli più lenti, a differenza del tuo team clienti, il cui numero più basso di stakeholder (una società cliente al posto del 100 team della tua piattaforma potrebbe alla fine servire) consente iterazioni più veloci.

Alla luce di tutto ciò, penso che potresti voler ripensare al nome "Prodotti principali", perché è solo confuso che tu stia creando prodotti "core" sulla piattaforma "core". Core significa dentro, quindi solo uno può essere quello.

Non posso credere che abbiano eliminato questo stackoverflow