I servizi aziendali devono intersecare i contesti?

1

In primo luogo, sto seguendo la convenzione che un contesto limitato è sinonimo di un dipartimento, o forse un dipartimento ha da 1 a molti contesti limitati.

Abbiamo un reparto di consulenza clienti che ha un servizio di documentazione. I documenti sono archiviati nel servizio di archiviazione documenti (che è il luogo in cui sono archiviati tutti i documenti dell'azienda - si tratta di un servizio di utilità) e il servizio di documentazione memorizza le informazioni su tale documento (un servizio aziendale). Poiché è stato progettato per la consulenza del cliente, è un'informazione pertinente.

Ora la salute e la sicurezza hanno bisogno di un posto dove archiviare le informazioni su un documento. Si tratta di informazioni diverse per la consulenza del cliente, ma mi è stato richiesto di estendere il servizio esistente per tenere conto di queste informazioni aggiuntive. Sento che questo servizio sta attraversando un contesto limitato. La mia preoccupazione è che tutti i dipartimenti finiranno per archiviare le informazioni qui e il servizio diventerà gonfio, cercando di essere tutto in tutti i reparti. Ogni record di documento memorizzerà solo un sottoinsieme delle informazioni in quanto appartenerebbe a un solo dipartimento.

Diventerà peggio quando diversi dipartimenti vogliono archiviare le stesse informazioni ma fare riferimento ad essi in modi diversi, o quando due dipartimenti vogliono memorizzare informazioni diverse a cui si riferiscono nello stesso modo. A mio avviso, questo è esattamente il motivo dei contesti limitati.

Ritengo che ogni dipartimento dovrebbe avere il proprio servizio aziendale per informazioni su un documento, ma utilizzare lo stesso servizio di utilità per archiviare effettivamente il documento.

Quale sarebbe l'approccio corretto?

    
posta Paul T Davies 18.10.2012 - 15:45
fonte

2 risposte

1

Probabilmente hai appena identificato la necessità di una funzione che non è specifica per un singolo dipartimento, ma piuttosto una sorta di infrastruttura di base. Considerare la possibilità di formare un contesto limitato "Infrastruttura di base" e assegnare lì il servizio di documentazione. In questo modo, ci sono confini e dipendenze chiari tra i diversi contesti. Il servizio di documentazione di base può ancora essere consumato da qualsiasi reparto, senza compromettere la progettazione.

Considera implementazioni specifiche in cima del servizio di documentazione più generico per gestire funzioni specifiche di un dipartimento (o meglio: funzione aziendale). Tali implementazioni specifiche dovrebbero quindi appartenere al rispettivo contesto limitato. Per es.

  • Infrastruttura di base: GenericDocumentationService (documento, attributi) - dove documento è il documento da memorizzare, attributi è un elenco di chiave / valore paris
  • Consulenza clienti: ConsultancyDocumentationService (documento, client)
  • Salute e sicurezza: HealthSafetyDocumentationService (documento, rischio, mitigazione)

Le implementazioni di sicurezza del cliente e della salute, ad es. convalidare ed elaborare i loro argomenti specifici, quindi utilizzare il servizio generico per archiviare definitivamente il documento.

NB: In generale, le strutture organizzative aziendali come i dipartimenti non costituiscono dei buoni limiti. Motivazione: le strutture organizzative tendono a cambiare nel tempo e tali cambiamenti possono invalidare i confini precedentemente identificati. Invece è consigliabile identificare le funzioni di core business e raggrupparle in blocchi logicamente coesivi.

    
risposta data 16.12.2012 - 15:54
fonte
0

Non vi è alcun motivo per cui il servizio di informazioni sul documento non possa essere progettato in modo che le informazioni contenute in esso contenute rimangano nei rispettivi contesti limitati. In effetti immagino che questa sarebbe una conseguenza naturale di come potresti progettare di progettare il sistema, se non è già stato progettato in questo modo.

Se il tuo sistema ha login o gruppi, e i documenti sono conservati nel login / gruppo in cui sono stati creati, allora questo raggiungerà l'obiettivo di cui sopra.

Sto confrontando il tuo sistema informativo del documento con una wiki aziendale. Un wiki può essere utilizzato da un'intera organizzazione di lavoro di > 1000 e potrebbe contenere pagine che sono terribilmente importanti per una persona ma complete a parole incomprensibili, eppure tutto va bene perché le rispettive business unit hanno generalmente un proprio insieme di pagine per lo più discrete il wiki che altre business unit ignorano o non sono nemmeno a conoscenza.

Sì, potrebbe essere necessario estendere la tua applicazione per coprire un pubblico più ampio e più generale, ma questo è l'obiettivo / incubo di qualsiasi applicazione reale. Pensa a qualsiasi sistema di database: il suo obiettivo è risolvere i problemi di archiviazione dei dati di tutti ovunque. È discutibile quanto bene lo facciano, ma non possono fallire perché tutti li stanno usando.

    
risposta data 15.11.2012 - 13:19
fonte

Leggi altre domande sui tag