Le classi di dominio sono un componente?
Un componente è qualcosa di autonomo e sostituibile con interfacce ben definite:
A Component is a self-contained unit that encapsulates the state and
behavior of a number of Classifiers. A Component specifies a formal
contract of the services that it provides to its clients and those
that it requires from other Components or services in the system in
terms of its provided and required Interfaces.
A Component is a
substitutable unit that can be replaced at design time or run-time by
a Component that offers equivalent functionality based on
compatibility of its Interfaces.
- UML 2.5 standard, section 11.6.3.1, Semantics of components
Ma le interfacce non devono necessariamente essere concepite come un artefatto tecnico, come un java interface :
An Interface specifies a contract; any instance of a Classifier that
realizes the Interface shall fulfill that contract. The obligations
associated with an Interface are in the form of constraints (such as
pre- and postconditions) or protocol specifications, which may impose
ordering restrictions on interactions through the Interface.
- UML 2.5 standards, section 10.4.3.1, Semantics of interfaces
Le tue classi di dominio dovrebbero essere autosufficienti, sostituibili e avere interfacce chiare, quindi puoi considerarle come un componente:
- Autonomo: non vi è alcun motivo per cui dipenderebbero da qualsiasi altra cosa di
ExamResults e ExamResultsDAO .
- Interfacce: quelle usate da
ExamResults e ExamResultsDAO (o esplicite interface , o implicite tramite i loro elementi public )
- Sostituibile: potresti sostituire la loro implementazione con un'altra purché rispetti le stesse interfacce per offrire lo stesso comportamento.
Il componente deve stare in piedi da solo?
Il tuo servizio ExamResults offre un servizio applicativo, che è quello di leggere i dati JSON e memorizzarli in un database. Per svolgere il suo lavoro ha bisogno di:
- un gestore di richieste: dipende dall'interfaccia e dai protocolli supportati dal servizio dell'applicazione (ad esempio richieste HTTP? messaggi SOAP? chiamate di funzione remote?)
- un parser: dipende dal formato utilizzato per gli esami. Ecco qui per JSON. Domani potresti cercare XML perché devi interconnetterti con un altro sistema di un'altra università.
-
ExamDAO : dipende dal database utilizzato. Le classi DAO non sarebbero implementate nello stesso modo, se si tratta di un database SQL o di un database NoSQL (ad esempio archivio di valori-chiave, database di grafici o database basato su documenti).
- Modello di dominio: dipende esclusivamente dal modello di dominio e non dal formato dei dati, né dai protocolli tecnici, né dal DBMS utilizzato
Ciò suggerisce che ci sono grandi vantaggi nell'isolare il modello di dominio dal resto, al fine di applicare separazione delle preoccupazioni .
Bene, sarebbe stato molto più rapido puntare su architettura pulita per supportare giungere a questa conclusione. Tuttavia, tutto questo ragionamento è valido qualunque altro modello di architettura tu abbia scelto.
Altre riflessioni
Il tuo microservizio svolge solo una piccola attività in un sistema più ampio. Altri microservizi potrebbero utilizzare i dati nel database ed eseguire altre attività. Potrebbe essere allettante quindi riutilizzare le classi di dominio e le classi DAO in questo contesto. Per il progetto scolastico è bello. Tuttavia, sii cauto:
-
microservizio sono concepiti per essere il più possibile disaccoppiati. La condivisione di codice comune crea tuttavia un accoppiamento nascosto tra le cose che dovrebbero rimanere indipendenti, il che potrebbe richiedere dei vincoli per l'implementazione di nuove versioni.
- in un panorama di microservizi, il database condiviso crea un accoppiamento ancora più strong tra i servizi. Per le applicazioni di big data può anche diventare un collo di bottiglia, in quanto potrebbe limitare la scalabilità.