Come collegare le specifiche di dominio con l'implementazione del codice senza forzare l'esperto di dominio ad adottare una particolare pratica

Our current business process is that the domain experts will write down the business logic in a Word document, and developers will try to reflect those logic as closely as possible with the implementation.

This process violates the DRY (do not repeat yourself) principle, and thus creates many problems that are associated with violating DRY principle.

Il problema qui è mantenere questo documento word come se avesse un significato oltre a quando il programmatore lo consuma per primo.

Se il programmatore sta creando una DSL o una lingua ubiquitaria in DDD, la logica di business dovrebbe essere qualcosa che un esperto di dominio possa facilmente ispezionare direttamente. Dovrebbe anche essere privo di qualsiasi elemento tecnico che distolga dal focalizzarsi sulla politica di alto livello.

Non siamo al punto in cui è possibile forzare l'esperto di domini a scrivere la logica aziendale effettiva. Ma se lo fai bene, possono leggerlo e dirti se hai dimenticato qualcosa o stai facendo qualcosa di sbagliato.

Quindi sì, quel documento word diventerà obsoleto. Va bene. Non dovrebbe essere tenuto aggiornato. La logica di business dovrebbe essere qualcosa su cui il tuo esperto di dominio può stampare e scarabocchiare. Non dovrebbe essere qualcosa che hanno scritto con parole.

Onestamente non vedo alcun problema, in termini di processo, con il tuo attuale sistema. Tutto ciò che deve essere fatto qui è un semplice cambio di paradigma nel modo in cui voi ragazzi trattate e pensate ai documenti che delineano le regole di business.

Il primo cambiamento qui è quello di dimenticare di usare questi documenti come una sorta di documentazione analoga alla documentazione del codice. Stai colmando un vuoto che non deve essere colmato, e farlo è a detrimento di tutti. Gli esperti di dominio documentano i requisiti e i processi aziendali che sono importanti per il business. Oltre a usare l'Ubiquitous Language (che si forma a questo livello e permea verso il basso), questi documenti hanno niente da fare con il tuo codice base o la sua implementazione. La documentazione del codice è di natura tecnica e non deve essere combinata con regole che riguardano il processo.

Sembra che voi ragazzi stiate cercando di trovare una via di mezzo tra l'esperto di domini e lo sviluppatore in modo tale che gli esperti possano creare una sorta di pseudo-codice che viene tradotto in codice reale. Inoltre, ti piacerebbe imporre delle regole al processo che per assicurarti che la traduzione non avvenga solo, ma che sia anche corretta. A quel punto, perché non basta che gli esperti di dominio scrivano il codice vero ?! Il motivo per cui il tuo lavoro esiste è che gli esperti di dominio possono concentrarsi sul dominio e puoi concentrarti sul codice (l'implementazione tecnica). Attualmente, i ruoli entrambi sembrano concentrarsi sulla cosa sbagliata (suppongo sia per questo che vuoi una soluzione automatizzata).

Il secondo passaggio è, in parole povere, i documenti aziendali non possono essere modificati, ma solo sostituiti. Quando un nuovo documento sostituisce un vecchio documento, il codice base viene modificato per riflettere le nuove regole. Fondamentalmente, questo è solo il controllo della versione.

Non ci sarà mai un buon modo per sapere a livello di programmazione se le modifiche a un documento commerciale sono state riflesse nel codice (dimenticalo correttamente). Mi viene la nausea solo immaginando il pasticcio che un tale sistema creerebbe. Si possono trovare soluzioni migliori dando un'occhiata al processo stesso (introducendo "ticket", ad esempio). Se questa è una parte così importante del tuo processo aziendale, sicuramente aggiungerà qualche semplice infrastruttura per gestirla. Anche l'inclusione di una suite di test automatizzata può essere molto utile.

E per quello che vale, una stretta comunicazione tra esperti di dominio e sviluppatori è una buona cosa.