Az alkalmazásfejlesztésben viszonylag gyakorinak tekinthető az a megközelítés, hogy elsőként a rendszer adatbázisait, az adatbázis táblákat és a kapcsolódó nézeteket kezdjük el megtervezni és megvalósítani, majd erre kerülnek felépítésre a rendszer további rétegei, mint az üzleti logika és felhasználói felület réteg.

Egy másik tipikus módszer ennek éppen a fordítottja, miszerint először a felhasználói felületeket és a rajta megjelenítendő elemeket konstruáljuk meg. Ezek a tradicionális megközelítések a későbbiekben általában óhatatlanul befolyásolják a szemléletünket, sokkal inkább adatokban és nem folyamatokban kezdünk el gondolkodni egy adott üzleti problémáról. Számos esetben ez nem csak a konkrét implementációra, de a kommunikációra is kifejti hatását; a különböző szerepköröket betöltő személyek (pl. felhasználók, üzleti elemzők, fejlesztők, tesztelők) között sok esetben eltérő terminológia alakul ki a projekt során, ezért hiába beszélnek ugyanarról az üzleti problémáról, mégis nehézséget okoz a másik megértése.

A domain-vezérelt tervezés (Domain Driven Design) szakít ezekkel a hagyományokkal és a fő fókuszt az üzleti domainre helyezi. A klasszikus szoftverfejlesztési módszertanokhoz képest ez egy merőben eltérő megközelítés, mivel ebben az esetben az adatbázisok szerkezete vagy a felhasználói felületek működése teljesen másodlagos; az alapvető cél, hogy megpróbáljuk minél pontosabban modellezni a valóságnak azon szeletét, amelyet az üzleti folyamatok körül határolnak. Ezt csak úgy lehet magas szinten kivitelezni, ha megismerjük az adott üzleti terület vagy iparág által végzett műveleteket, illetve elsajátítjuk a kapcsolódó szakkifejezéseket, mely által egy közös nyelvet (ubiquitous language) fogunk beszélni a projekt szereplőivel. A domain komplexitásától függően ez akár egy hosszabb tanulási folyamatot is jelenthet, a végtermék minősége szempontjából ugyanakkor kifizetődő.

A domain szoftver-szintű leképezésére a domain-vezérelt tervezés a következő fogalmakat definiálja

Entitás (Entity): Önálló identitással rendelkező objektum. Entitások lehetnek például a szállítók, akiket az adószámuk egyértelműen azonosít. Ha két szállítónak megegyezik az adószáma, akkor ugyanarról az objektumról beszélünk.

Értékobjektum (Value object): Olyan objektum, amelyet a tulajdonságai alapvetően definiálnak. Ha két objektum tulajdonságai megegyeznek, akkor azonosnak tekinthetők. Értékobjektum lehet például a cím, amely rendelkezik irányítószámmal, településnévvel, utcanévvel és házszámmal. Az értékobjektumok sajátossága, hogy nem módosíthatóak, hiszen, ha például egy címnek változna a házszáma, akkor az már egy teljesen másik címet reprezentálna.

Aggregátor (Aggregate): Olyan entitás, amely más entitásokat és értékobjektumokat foglal össze. Egyfajta tranzakciós határt is definiál a rendszerben, mivel az általa tartalmazott objektumokat csak rajta keresztül lehet elérni és módosítani. Az aggregátorok más aggregátorokat sohasem tartalmazhatnak, de hivatkozhatnak egymásra. Aggregátor lehet például a számla, amelyet a számlaszám egyértelműen azonosít, illetve több tételt is tartalmazhat. A tételek tipikusan csak a számla vonatkozásában értelmezhetők ezért, ha például egy számla törlődik a rendszerből, akkor a kapcsolódó tételeket is törölni szükséges.

Domain esemény (Domain event): Az aggregátorokon bekövetkezett időbeli változásokat reprezentáló objektumok. Domain esemény lehet például egy számla létrejötte, vagy egyik tételének törlése.

Adattár (Repository): Az aggregátorokon elvégezhető műveleteket definiáló objektum. A domain szintjén az adattár csak egy absztrakciót (interfészt) reprezentál, amelyet a rendszer egy külső rétegében egy adapter (pl. egy adatbáziskezelő ORM) valósít meg.

Szolgáltatás (Domain and application service): Olyan műveletek, amelyek nem kapcsolhatók közvetlenül egyik entitáshoz sem. Szolgáltatás lehet a számla létrehozását megvalósító objektum, amely például az adattár segítségével először ellenőrzi, hogy szerepel-e már az adott azonosítóval számla a rendszerben, és ha nem, akkor a felhasználói felületen megadott adatok alapján létrehozza azt. Technikai jellegű szolgáltatások is előfordulnak, mint például a felhasználók azonosítását vagy SMS küldést végző szolgáltatások.

Domain Model: A fenti fogalmak alapján tartalmazza és rendszerbe foglalja mindazon üzleti tudást, amely a rendszer kialakításához szükséges és annak egyben alapja. A domain model a projekt során folyamatosan fejlődik, egyre magasabb minőségi szintet ér el, ahogyan az üzleti probléma egyre érthetőbbé, megértése egyre teljesebbé válik.

Általánosan igaz, hogy a valóságból leképezett objektumok tulajdonságait a kontextus alapvetően befolyásolja. Ez különösen érvényes mikroszolgáltatás alapú rendszerek esetében, ahol az egyes subdomain-ekben is már másként lehet értelmezni egy-egy objektumot.

Egy törzsadatkezelő modul a szállítókról például nyilvántarthat adószámot, bankszámlaszámokat, kapcsolati adatokat, miközben ugyanezt egy értesítés-kezelő modul mindössze egy email címmel reprezentálja. Az objektumok típusa szintén eltérő lehet a különböző subdomain-ekben: a törzsadatkezelő modulban a szállító például tipikusan egy aggregátor, míg a számlakezelő modul vonatkozásában entitásként vagy értékobjektumként is értelmezhető. Nincsenek kőbe vésett szabályok, az optimális modell az adott (sub)domain alapos megismerésének az eredménye.

A domain-vezérelt tervezési szemlélet alapvetően jól illeszkedik a mai modern fejlesztési módszertanokhoz (clean architecture, CQRS), továbbá segíti a közös gondolkodásmód kialakítását a különböző szerepköröket betöltő személyek és üzleti területek között. A módszer sajátossága, hogy az üzleti terület által definiált folyamatok és a kapcsolódó terminológia a rendszer dokumentációiban, illetve kódbázisában is egy az egyben visszatükröződnek. Ez a fajta megközelítés nagymértékben megkönnyíti a kommunikációt, a rendszer karbantartását, bővítését és tesztelését, valamint elősegít minket abban, hogy egy magasabb minőséget képviselve tudjuk kiszolgálni az ügyfelek igényeit.