Vedo questo termine molto nel contesto dell'architettura software ("domain-model", "domain-driven-design" ecc.). L'ho cercato su google, ma ho un sacco di definizioni diverse. Allora, cos'è veramente?
La parola "dominio" nel libro Domain Driven Design di Eric Evans ha un significato specifico. È la cosa di cui tratta il software.
Evans va oltre però. Nella sua visione ci sono sottodomini anche con lo stesso software. E questa è la parte del libro che tratta di "Strategic Design".
Esistono tre "domini": il dominio principale, il dominio di supporto e il dominio generico. A volte si riferirà a questi come sottodomini.
Anche a Evans interessa profondamente l'attività reale che sta dietro al software e il libro non è solo rivolto agli sviluppatori, ma anche architetti e manager che hanno bisogno di vedere come il software e l'azienda possono lavorare insieme, e questo è ciò a cui si preoccupa quando discutendo la progettazione strategica e questi sottodomini.
Quindi, il dominio principale è la parte del software che rappresenta sia il vantaggio competitivo sia la "ragione d'essere" del software. È la parte del software che è il motivo per cui un cliente acquisterebbe il software rispetto ad altri software. Di solito, Evans lo vede come il dominio contenente la più piccola percentuale di codice. Puoi pensare ad esso come il 20% più importante. È la parte che non puoi davvero comprare dallo scaffale e potrebbe essere solo un singolo modulo o componente del software in generale.
Il dominio di supporto è ancora importante e può essere univoco per l'organizzazione, ma non è importante quanto il dominio principale. Senza di esso, il software non sarà così prezioso e il core si basa su di esso. Potrebbe essere più moduli nel software che hai scritto tu stesso e che svolgono funzioni importanti ma di supporto al nucleo.
Il dominio generico è il meno personalizzato e, in un certo senso, la parte meno importante del software. Potresti averlo scritto in casa, ma potrebbe essere più efficiente semplicemente acquistarlo dallo scaffale o usare 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 pacchi o un sistema di registri sanitari che gestisce i pazienti, il dominio generico è la parte di questi sistemi che sono comuni e solo semplicemente bisogno di essere lì per funzionare a tutti. Questo probabilmente costituisce la maggior parte del sistema in generale, ma non necessariamente.
Da un punto di vista aziendale è importante decidere qual è il tuo dominio principale e concentrare le risorse di sviluppo lì. Evans ha molti video, in particolare sul sito InfoQ, in cui 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.
Devo notare che i concetti di DDD non esistono necessariamente nella più ampia comunità di software. Altri sviluppatori, autori e addetti ai prodotti possono avere idee e definizioni diverse, altre più sottili e altre meno. Anche altri autori che hanno scritto sulla DDD potrebbero sorvolare 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 reale in cui stai tentando di risolvere un problema utilizzando il software. Ogni dominio viene fornito con esperienza, vocabolario e strumenti che fanno parte di quel dominio.
Un esempio specifico di dominio potrebbe essere qualcosa come "la lavorazione automatizzata di parti complesse usando una fresa rotante ad alta velocità". Il sistema software e hardware che lo compie è chiamato CNC mulino .
Un altro esempio di dominio è il reparto contabilità di una società.
Ulteriori letture
Contesto limitato di Martin Fowler
Significa semplicemente lo spazio del problema su cui stai lavorando. Ad esempio, se stavi creando un sito 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 per rappresentare un prodotto o una fattura o un record di spedizione.
Un dominio è un'area di conoscenza. Può trattarsi di un'attività in cui esistono problemi risolti dal software. ( Wiki , Comunità DDD )
Eric Evans nel suo libro usa la spedizione cargo per spiegare che cos'è il DDD. Nel suo esempio, dominio è tutto su spedizione . Come spostare, gestire, spedire e tracciare il carico, ecc. Viene fornito con regole, linguaggio e processi specifici. Quelli creeranno modelli di dominio, oggetti, servizi e così via.
Quando crei un'applicazione, avrai una sorta di autorizzazione, proprio come nel mondo reale della spedizione, non tutti possono accedere ai magazzini. In che modo gli utenti sono autorizzati e in che modo vengono concesse le autorizzazioni possono essere al di fuori di dominio , perché le informazioni potrebbero non essere rilevanti per la spedizione del carico.
In poche parole: un dominio è dove si fa business . Se la tua attività commerciale è la spedizione del carico, il carico sarà il tuo dominio. Se la tua azienda sta effettuando l'autenticazione e l'autorizzazione del personale, questo sarà il tuo dominio.
Da Design guidato da domini: affrontare la complessità nel cuore del software , Eric Evans:
Every software program relates to some activity or interest of its user. That subject area to which the user applies the program is the domain of the software.
The domain of an airline-booking program involves real people getting on real aircraft.
The domain of an accounting program is money and finance.
The domain of a source-code control system is software development itself.
Il modello di dominio, quindi, è "un'astrazione rigorosamente organizzata e selettiva di" la conoscenza nella testa di un esperto di dominio.
Palermo, nel descrivere l'architettura della cipolla, ha offerto questo riassunto
In the very center we see the Domain Model, which represents the state and behavior combination that models truth for the organization.
Fowler, a sua volta, offre
An object model of the domain that incorporates both behavior and data.
Se stai guardando definizioni più recenti, è più probabile che tu ricerchi riferimenti a il modello di dominio e il modello di dati sono diversi . Non considero questo cambiamento di significato tanto quanto un cambiamento di enfasi: la modellazione dei comportamenti (il modo in cui i dati cambiano in risposta alle informazioni dall'esterno del modello) ha una complessità e una variazione più ricca rispetto ai diversi modi di scrivere le cose verso il basso .
Dato che probabilmente hai già un'idea di cosa sia il dominio, immagino che il prossimo passo che dovrai compiere sia cercare di definire sottodominio, modello di dominio e, soprattutto, contesto limitato.
Comincio con il mettere la mia prospettiva di dominio però.
Il dominio è la realtà che abitiamo: le sue entità, il loro comportamento, le leggi a cui obbediscono. Esisteva prima di noi e ci sarà dopo di noi, in una forma o nell'altra. La sua esistenza non dipende dalla nostra consapevolezza. I marketer presentano nuove funzionalità e 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.
Il DDD implica la decomposizione del dominio in sottodomini, per facilitarne la modellazione e la comprensione. Il fatto stesso che gestisci un'impresa deduce che esiste almeno un valore aziendale predominante. Quello con cui guadagni soldi. Quello per cui abbiamo iniziato il nostro business. Quindi, anche se non conosci una parola come "Dominio core", è ancora presente. Lo stesso vale per i sottodomini: probabilmente avrai bisogno di una contabilità, risorse umane, supporto tecnico - ma è secondario.
Non è necessario modellare i sottodomini estratti nella loro interezza. C'è un certo insieme di regole in ogni sottodominio che ci interessa. Una serie di regole in alcuni sottodomini necessari per ottenere un determinato risultato aziendale è chiamata modello.
La cosa più importante è che il contesto limitato è un limite logico.
Quando vengono definiti sia i sottodomini sia il dominio principale, è il momento di implementare il codice. Il contesto limitato definisce i limiti tangibili dell'applicabilità di alcuni sottodomini. È un'area in cui un determinato sottodominio ha senso, mentre gli altri no. Può essere un discorso, una presentazione, un progetto di codice con limiti fisici definiti dall'artefatto.
Se sei interessato a come il concetto di contesto limitato è correlato al concetto di sottodominio, come definire sottodomini e contesti limitati, come rappresentare la comunicazione reciproca e come organizzare team con questi concetti in mente, probabilmente dovresti essere interessato a questo ulteriore lettura .
Leggi altre domande sui tag domain-driven-design terminology domain-model domain-objects