Nella progettazione basata su domini, le entità sono autorizzate a gestire operazioni complesse come I / O?

Naviga le tue risposte
1

Panoramica

Sto cercando di apprendere il design basato sul dominio, e io sono circa l'80% del modo attraverso il libro di Eric Evan sull'argomento (e circa lo stesso sul corso Pluralsight). Ho cercato di applicare ciò che ho imparato riprogettando un vecchio progetto LabVIEW / TestStand, ma sono preoccupato che sia corretto avere quelle che considero come le entità che eseguono I / O logica, come la comunicazione CAN / Modbus. L'approccio che sto prendendo ora non è molto lontano da quello che ho fatto in precedenza, e finora ha funzionato bene per me, quindi sono abbastanza fiducioso. Tuttavia, mi piacerebbe vedere se c'è ancora spazio per miglioramenti osservando il processo di sviluppo da una prospettiva DDD.

Oltre a questo, spero di ottenere solo la convalida sull'approccio che ho assunto in generale. Per questo motivo, questo post sarà un po 'prolisso - mi dispiace in anticipo.

Sfondo

Questo progetto è incentrato sull'esecuzione di test automatici di una determinata marca di meccatronici (parte del sistema di trasmissione dei veicoli). Ho dato il via al progetto collaborando con un mio collega che ha meno esperienza nello sviluppo di software orientato agli oggetti, ma un sacco di esperienza nel test dell'hardware automobilistico. In questo senso, ha svolto il ruolo di esperto di dominio . Usando una lavagna ho modellato l'attrezzatura di prova e ho annotato le definizioni di alcune delle terminologie che ha usato (queste sono diventate parte del linguaggio ubiquitario ):

Quandohoiniziatoasviluppareilprogetto,l'hoformalizzatoinundiagrammadiclasseUML.Loschemaseguenteèl'ultimarevisione,leggermentediversadallaprimaversioneacausadiunacomprensioneincontinuaevoluzionedeldominio:

Allo stadio in cui sono ora, ho creato la maggior parte dell'architettura complessiva dell'applicazione e implementato la maggior parte della logica. Ho fatto la maggior parte del codice, lasciando i segnaposto per il mio collega esperto di hardware da riempire con la logica dell'hardware reale. Ci scambiamo avanti e indietro con git, con la mia workstation ideale per scrivere la maggior parte del codice e la sua per testarla contro apparecchiature hardware reali (alimentatori, motori, ecc.). Fin qui tutto bene.

Tipicamente,ilmioapproccioallaprogettazionediquesteapplicazioniconsistenelcreareunalibreria"utility" LabVIEW che modella il banco di prova e tutte le risorse su di essa, e file di sequenza TestStand che fanno uso di questa libreria, eseguendo una sequenza di passi precedente come "Accendi l'alimentatore", "Imposta il motore su 1000 RPM", "Misura le pressioni e controlla i limiti", ecc.

Considerando questo da una prospettiva DDD, sembra che la libreria LabVIEW costituisca il livello di dominio , mentre i file di sequenza di TestStand costituiscono il livello di applicazione , che utilizza e organizza le classi nella libreria che rappresentano il dominio per eseguire una sequenza di test effettiva che ha valore per la nostra attività. Inoltre, il VB test rig sembra servire da radice aggregata composta da entità come alimentazione , array di flussometri e così via.

Crux Of Problem

Ecco dove sono un po 'insicuro: Eric spiega che le classi di entità dovrebbero certamente contenere un comportamento appropriato a qualsiasi cosa esse rappresentino (fare altrimenti comporterebbe un modello di dominio anemico ). Tuttavia, tutte le classi di entità nel suo libro (come Customer o Account ) tendono ad avere un comportamento relativamente "semplice" - una classe Customer non ha bisogno di eseguire I / O, per esempio.

È appropriato che io pensi ancora a alimentazione e array di flussometri come entità (quando sono chiare parti del dominio e linguaggio ubiquitario) nonostante il Infatti, implemento ZPL Power Supply con comunicazione seriale e DAQ Flow Meter Array con logica di acquisizione dati?

Inoltre: ho applicato correttamente i principi DDD o c'è spazio per miglioramenti? DDD è appropriato anche per un progetto come questo?

    
posta Tagc 30.04.2018 - 10:58
fonte

2 risposte

3

Penso che DDD non sia progettato pensando a questo tipo di progetto.

Dal mio punto di vista, DDD si occupa principalmente di collegare la lingua del business con l'attualità sottostante del codice.

Ad esempio un venditore dice: "I Venduto 100 Widget in Q1 " uno sviluppatore dice: "c'erano 100 ordini nel database con stato completo e tipo "widget_v3" e data di completamento tra 2001-01-01 e 2001-04-01 collegato a employeeId 12 "

Questo porta a confusione, DDD vuole far riflettere gli sviluppatori e progettare nel linguaggio commerciale.

Nel tuo caso mi sembra che il linguaggio commerciale corrisponda già alla realtà tecnica sottostante. Le cose che stai testando hanno definizioni tecniche di ciò che fanno e tutti usano questi termini per parlarne. In tal caso DDD è solo OOP e va bene inserire un codice dettagliato nei metodi (sebbene sia meglio iniettarlo come servizio)

    
risposta data 30.04.2018 - 13:39
fonte
2

Is it appropriate for me to still think of power supply and flow meter array as entities (when they're clear parts of the domain and ubiquitous language) despite the fact that I implement ZPL Power Supply with serial communication, and DAQ Flow Meter Array with data acquisition logic?

Probabilmente no.

Un concetto importante da comprendere nella modellazione è book of record . Capital-T Truth è nel modello, o da qualche altra parte (il mondo reale).

La mia immagine preferita della differenza è carrelli della spesa . Quando il modello di Amazon rimuove un oggetto dal mio carrello, non c'è più. Ma se cancello la scatola di cereali dall'Assistente commerciale sul mio telefono, la scatola non torna magicamente sullo scaffale.

L'array di alimentazione e misuratore di portata mi assomiglia come all'esterno del tuo modello che sono le fonti di informazione ricevute dal tuo modello. Allo stesso modo, probabilmente stai inviando messaggi a Pump Motor Drive e altri attuatori, piuttosto che includerli nel modello.

Se stavi scrivendo una simulazione di un alimentatore, allora queste cose potrebbero essere entità nel tuo modello.

In domain-driven design, are entities allowed to handle complex operations such as I/O?

Generalmente, no. È più probabile che un'entità modellata esegua operazioni complesse tramite un'API specifica del dominio (un "Servizio dominio"). Un esempio classico qui è "invia email" - di solito non includiamo un po 'di logica email nelle entità di dominio, ma piuttosto passiamo loro un'interfaccia che fornisce l'accesso alla funzionalità di posta elettronica (tipicamente implementata da un livello infrastruttura) .

    
risposta data 30.04.2018 - 19:16
fonte

Leggi altre domande sui tag

Servizio di posta elettronica nell'architettura dei microservizi Come utilizzare un'interfaccia REST per l'implementazione dei comandi delle attività sulla mia API Web?