Successivamente, il DDD richiede uno studio più approfondito dei Bounded Context chiamato Tactical Design.
Sono stati quindi analizzati nel dettaglio ciascuno di essi:
Shipping Context: esso mette a disposizione due aggregati: Shipping e Client.
Il primo di questi fonda le proprie basi sull’entità Order, la cui particolarità è il ciclo di vita collegato alla consegna del medesimo. Viene chiaramente supportato da Value Object indispensabili a rappresentare le informazioni che esso contiene. Esso inoltre agisce da aggregate root, perciò viene supportato da un repository apposito per fare in modo di assicurarsi che le informazioni rimangano persistenti e consistenti. Come raccomandato, per evitare lo State Pattern lo stato dell’ordine è stato realizzato come una collezione di differenti entità, ciascuna delle quali rappresenta lo specifico stato in quel momento. Per separare il più possibile la logica relativa agli ordini e alle consegne, sono stati modellati tre domain services:
NOTE: a causa del suo ruolo nel dominio e avendo evitato lo State Pattern, non sono presenti
ulteriori invarianti dell’entità Order oltre alla semplice validazione che la data di consegna
debba essere successiva alla data di ordinazione e che il nuovo tentativo di consegna non debba essere
precedente al vecchio.
L’aggregato Client invece, provvede, tramite un servizio apposito, le seguenti funzionalità:
Le notifiche sono gestite come Domain Event in quanto appunto eventi scatenati dalle corrispettive operazioni.
Drone Context: questo aggregato si compone di otto aggregati, di cui sette operano nel sistema del drone e uno nell’applicativo dell’utente. Gli aggregati del sistema del drone sono: Drone, Sensor, Proximity, Accelerometer, Camera, Alert e Order. L’applicativo dell’utente invece contiene il solo aggregato UserMonitoring.
L’aggregato Drone possiede le entità necessarie per poter gestire il drone intero, permettendone, ad esempio, l’attivazione e l’arresto oppure di operare sui suoi sensori. Esso contiene anche il service apposito per informare se il drone è stato arrestato, oppure se è ripartito per la consegna. Esso infatti a sua volta comunica con l’aggregato Sensor attraverso il suo aggregate root, ovvero SensorSet, che permette di maneggiare contemporaneamente tutti i sensori del drone, permettendo di gestirne l’attivazione e fornendo il necessario per leggere e pubblicare i loro dati. I servizi a disposizione dell’aggregato, gli permettono di analizzare tutti gli stati di allerta dei sensori per ottenere lo stato attuale del drone e di pubblicare il corrente stato d’allerta.
I sensori perciò sono suddivisi in tre aggregati: Proximity, Accelerometer e Camera. Ognuno di essi fornisce quindi le stesse operazioni del SensorSet ma, al contrario di quest’ultimo, essi operano ognuno sul rispettivo sensore, nelle modalità appropriate. Infatti contengono anche dei Service per poter processare, analizzare e, infine, pubblicare i dati dei loro sensori.
Infine sono presenti altri due aggregati per agevolare il funzionamento del contesto, fornendo i Value Object relativi agli ordini e allerte rispettivamente negli aggregati Order e Alert. Essi mettono a disposizione esclusivamente i value object necessari per il funzionamento del contesto, perciò non sono presenti dei service addizionali.
L’aggregato UserMonitoring invece è mirato al tracciamento dei messaggi inviati dal sistema del drone. Infatti possiede i value object per mantenere i dati ricevuti e due servizi, uno dei quali riceverà tutti i messaggi del drone relativi ai sensori, mentre il secondo permetterà di osservare lo stato della consegna e controllare il drone da remoto. Essi avranno inoltre il compito d’informare il resto del sistema attraverso l’uso dei rispettivi Domain Events. I messaggi in questione riguardano i dati di ogni sensore, i messaggi di allerta del drone e quelli relativi allo stato del movimento del drone (arrestato oppure in movimento).
Issue Reporting Context: questo contesto si occupa di gestire solo le segnalazioni riguardanti i malfunzionamenti. Esso è costituito da sei aggregati.
L’aggregato CreationIssue permette di creare una nuova segnalazione e successivamente spedirla per essere aggiunta al sistema. Infatti una segnalazione, prima di essere aggiunta al sistema, non possiede un identificativo, non essendo ancora parte del sistema. Per questo motivo sarà utilizzato l’aggregato CreatedIssue, che definisce le segnalazioni che sono già state aggiunte al sistema e sono quindi in possesso di un identificativo.
Dopo essere creata, una segnalazione diventa una segnalazione attiva che, a differenza di una chiusa, deve essere processata o è in fase. Questo tipo di segnalazioni sono rappresentate dall’aggregato ActiveIssue, che a sua volta può essere rappresentato da due ulteriori aggregati: OpenIssue e VisionedIssue. Questo aggregato come funzionalità, permette di ritrovare nel sistema tutte le segnalazioni attive, d’interesse all’utente che le sta richiedendo.
L’aggregato OpenIssue rappresenta la situazione in cui una segnalazione è stata appena creata. In questo stato nessun manutentore è ancora intervenuto in alcun modo per risolverla. Infatti permette al manutentore di eseguire l’operazione che la trasformerà in una visionata. Quest’ultima è definita dall’aggregato VisionedIssue, per rappresentare lo stato in cui un manutentore sta attualmente prendendo visione della segnalazione e sta lavorando a una possibile soluzione per risolverla. L’aggregato ha lo scopo di fornire al corriere l’informazione che la sua segnalazione è stata presa in carica e potrebbe essere risolta a breve. A questo scopo l’agregato mette a disposizione del manutentore una possibilità che gli permetta, alla fine dell’elaborazione della segnalazione, di chiudere la segnalazione, specificando la soluzione adottata.
Infine perciò è presente l’aggregato ClosedIssue, il quale rappresenta una segnalazione che è stata definitivamente chiusa. Quindi l’unica funzionalità che tale aggregato fornisce, è quella che permette a un utente di ritrovare tutte le segnalazioni chiuse che sono di suo interesse.
Negligence Reporting Context: al contrario questo contesto permette di occuparsi solo delle segnalazioni per negligenza. È presente un unico aggregato: Negligence Reporting.
Esso si occupa di effettuare la segnalazione, mediante il servizio appropriato (Drone Reporter). Verrà quindi generato un evento che avvisi della nuova segnalazione (New Negligence).
A questo punto, il modello è avvisato di una nuova segnalazione e perciò, da questo momento in poi, il supervisore assegnato a questa negligenza dovrà occuparsene, compilando un’apposita scheda di provvedimento.
User Context: questo contesto, relativamente di minor dominio, offre un singolo aggregato User, il quale offre le funzionalità base per ciò che concerne tutti gli utenti, come la possibilità di effettuare il login e il logout. Inoltre, per differenziare i tipi di utenti del sistema sono presenti estensioni dell’utente generico a seconda dei ruoli ricoperti da essi: attualmente sono presenti Courier e Maintainer. Infine, sono due i principali servizi legati a questo sotto-dominio: Authentication Service e User Manager. Il primo di questi permette di effettuare il login e il logout dal sistema. Il secondo invece, fungendo da gestore degli utenti, concede la possibilità di ricavare le informazioni relative a specifici utenti, così come all’utente che ha acceduto al sistema.