Vedo questo termine molto nel contesto dell'architettura software ("modello di dominio", "progettazione guidata dal dominio" ecc.). L'ho cercato su Google, ma ho tonnellate di definizioni diverse. Quindi cos'è davvero?

La parola "dominio" nel libro Domain Driven Design di Eric Evans ha un significato specifico. È la questione del software.

Evans va oltre. A suo avviso ci sono sottodomini anche con lo stesso software. E questa è la parte del libro che tratta del "Design strategico".

Esistono tre "domini": il dominio principale, il dominio di supporto e il dominio generico. A volte si riferirà a questi come sottodomini.

Evans si preoccupa anche profondamente del vero business alla base del software e il libro non si rivolge solo agli sviluppatori, ma anche agli architetti e ai manager che hanno bisogno di vedere come il software e il business possono lavorare insieme, e questo è ciò di cui si occupa quando discute della progettazione strategica e questi sottodomini.

Quindi, il dominio principale è la parte del software che rappresenta sia il vantaggio competitivo che la "ragion d'essere" del software. È la parte del software che è il motivo per cui un cliente dovrebbe acquistare il software rispetto ad altri software. Di solito, Evans lo vede come il dominio che contiene la più piccola percentuale di codice. Puoi considerarlo il 20% più importante. È la parte che non puoi davvero comprare dallo scaffale e potrebbe essere solo un singolo modulo o componente del software complessivo.

Il dominio di supporto è ancora importante e può essere unico per l'organizzazione ma non è importante quanto il dominio principale. Senza di esso, il software non sarà così prezioso e il nucleo si basa su di esso. Potrebbero essere più moduli nel software che hai scritto tu stesso e che svolgono funzioni importanti ma di supporto al core.

Il dominio generico è il meno personalizzato e in qualche modo la parte meno importante del software. Potresti averlo scritto in casa, ma potrebbe essere più efficiente acquistarlo dallo scaffale o utilizzare un noto software open source. Questa parte del sistema probabilmente non è specifica per il tuo dominio generale, quindi ad esempio se hai un sistema di spedizione che instrada i pacchi o un sistema di cartelle cliniche che gestisce i pazienti, il dominio generico è la parte di questi sistemi che sono comuni e solo semplicemente bisogno di essere lì per funzionare affatto. Questo probabilmente costituisce la maggior parte del sistema in generale, ma non necessariamente.

Dal punto di vista aziendale è importante decidere quale sia il tuo dominio principale e concentrare lì le tue risorse di sviluppo. Evans ha molti video, in particolare sul sito InfoQ, dove spiega questi concetti in modo più dettagliato.

Quindi, mentre parliamo spesso di "dominio" nel software, nel caso di DDD, non è così semplice come potrebbe sembrare.

Dovrei notare che i concetti di DDD non esistono necessariamente nella più ampia comunità di software. Altri sviluppatori, autori e persone del prodotto possono avere idee e definizioni diverse, alcune più sottili e altre meno. Anche altri autori che hanno scritto su DDD potrebbero ripassare questi concetti nel libro di Evans, ma ritengo che i concetti siano ancora utili quando si scrive e si pianifica un progetto software.

Il dominio è il contesto del mondo reale in cui stai tentando di risolvere un problema utilizzando il software. Ogni dominio è dotato di competenza, vocabolario e strumenti che fanno parte di quel dominio.

Un esempio specifico di un dominio potrebbe essere qualcosa come "la lavorazione automatizzata di parti complesse utilizzando una taglierina rotante ad alta velocità". Il sistema software e hardware che realizza questo è chiamato un mulino a controllo numerico .

Un altro esempio di dominio è il reparto contabilità di una società.

Ulteriore lettura
Contesto limitato di Martin Fowler

Significa semplicemente lo spazio problematico in cui stai lavorando. Ad esempio, se stavi costruendo un sito Web di e-commerce, il tuo dominio sarebbe "e-commerce" e coinvolgerebbe i processi associati alle pratiche di vendita del tuo cliente / azienda. Quindi un modello di dominio sarebbe qualcosa che rappresenti un prodotto o una fattura o un record di spedizione.

Un dominio è un'area di conoscenza. Può essere considerato come un'attività in cui esistono problemi risolti dal tuo software. ( Wiki , DDD Community )

Eric Evans nel suo libro, usa la spedizione di merci per spiegare cos'è DDD. Nel suo esempio, il dominio è tutto sulla spedizione . Come le merci vengono spostate, gestite, spedite e monitorate ecc. Viene fornito con regole, lingua e processi propri. Questi creeranno modelli di dominio, oggetti, servizi e così via.

Quando crei un'applicazione, avrai una sorta di autorizzazione, proprio come il mondo reale delle spedizioni, non tutti possono accedere ai magazzini. Il modo in cui gli utenti sono autorizzati e le autorizzazioni concesse possono essere al di fuori del dominio , poiché le informazioni potrebbero non essere rilevanti per la spedizione di merci.

In poche parole: un dominio è il luogo in cui fai affari . Se la tua attività è la spedizione di merci, la spedizione sarà il tuo dominio. Se la tua attività consiste nell'autenticare e autorizzare il personale, questo sarà il tuo dominio.

Da Domain-Driven Design: affrontare la complessità nel cuore del software , Eric Evans:

Ogni programma software si riferisce ad alcune attività o interessi del suo utente. L'area tematica a cui l'utente applica il programma è il dominio del software.

Il dominio di un programma di prenotazione aerea coinvolge persone reali che salgono su aerei reali.

Il dominio di un programma di contabilità è denaro e finanza.

Il dominio di un sistema di controllo del codice sorgente è lo sviluppo del software stesso.

Il modello di dominio, quindi, è "un'astrazione rigorosamente organizzata e selettiva della" conoscenza nella testa di un esperto di dominio.

Palermo, nel descrivere l'architettura delle cipolle, ha offerto questo riassunto

Al centro vediamo il modello di dominio, che rappresenta la combinazione di stato e comportamento che modella la verità per l'organizzazione.

Fowler, a sua volta, offre

Un modello a oggetti del dominio che incorpora sia comportamento che dati.

Se si stanno esaminando definizioni più recenti, è più probabile che si verifichino riferimenti che il modello di dominio e il modello di dati sono diversi . Non ritengo che un cambiamento di significato tanto quanto un cambiamento di enfasi: modellare i comportamenti (il modo in cui i dati cambiano in risposta a informazioni esterne al modello) ha una complessità e una variazione più ricche rispetto ai diversi modi di scrivere le cose .

Dato che probabilmente hai già un'idea di cosa sia il dominio, immagino che il prossimo passo che farai è cercare di definire il sottodominio, il modello di dominio e, soprattutto, il contesto limitato.

Comincio col mettere la mia prospettiva di dominio però.

Dominio

Il dominio è la realtà in cui abitiamo: le sue entità, il loro comportamento, le leggi a cui obbediscono. Esisteva prima di noi e esisterà dopo di noi, in una forma o nell'altra. La sua esistenza non dipende dalla nostra consapevolezza. Gli esperti di marketing presentano nuove funzionalità ed eseguono analisi di mercato, i key account manager comunicano con i clienti, gli sviluppatori di software automatizzano i processi aziendali. Ecco perché il dominio è chiamato spazio Problema.

Sottodomini

DDD implica la decomposizione del dominio in sottodomini, per facilitarne la modellizzazione e la comprensione. Il fatto stesso che tu gestisca un'attività implica che esiste almeno un valore aziendale predominante. Quello con cui guadagni soldi. Quello per cui abbiamo iniziato la nostra attività. Quindi, anche se non conosci una parola come "Dominio principale", è ancora presente. Lo stesso vale per i sottodomini: probabilmente avrai bisogno di una contabilità, risorse umane, supporto tecnico - ma è secondario.

Modello di dominio

Non è necessario modellare i sottodomini estratti nella loro interezza. Esiste un determinato insieme di regole in ogni sottodominio a cui siamo interessati. Un insieme di regole in alcuni sottodomini necessario per ottenere un determinato risultato aziendale è chiamato modello.

Contesti limitati

La cosa più importante è che il contesto limitato è un confine logico.

Quando vengono definiti sia i sottodomini che il dominio principale, è il momento di implementare il codice. Il contesto limitato definisce i confini tangibili dell'applicabilità di alcuni sottodomini. È un'area in cui un certo sottodominio ha senso, mentre gli altri no. Può essere un discorso, una presentazione, un progetto di codice con confini fisici definiti dal manufatto.

Qual è il prossimo?

Se sei interessato a come il concetto di contesto limitato si correla con il concetto di sottodominio, come definire sottodomini e contesti limitati, come rappresentare la loro comunicazione reciproca e come organizzare i team con questi concetti in mente, probabilmente ti interesserebbe questo ulteriori letture .