Con Domain Driven Design si modellerebbe il dominio. Uno quindi userebbe un ORM di qualche tipo per prendersi cura della persistenza. Supponiamo che tu abbia un'entità Product che ha un Name , SKU e un Owner . Questo verrà modellato e quando viene creato un nuovo Product è necessario passare tutti i 3 campi come parametri nel costruttore.
Quanto sopra sarà mantenuto da Fluent NHibernate usando un database Postgresql.
Il Owner del prodotto è di tipo Account . Account è un'entità che contiene ID , FirstName , LastName , Email , Phone , Username , Password e Address .
Il Account deve essere persistente in due database. Deve persistere in Application Database ( Postgresql Server ) in modo che possa esistere un collegamento tra Product e Account . Tuttavia, deve anche essere salvato sul server 389 Active Directory . Questo server AD contiene tutti i record utente e le loro informazioni.
Non voglio duplicare tutti i dati che sono memorizzati sul server Active Directory e salvarlo su Application Server . Sulla Application Server voglio salvare FirstName , LastName , Email e ID .
Se un utente sceglie di modificare i dettagli di Account , aggiornerà quindi Active Directory Server e i campi memorizzati in Application Server .
es. Un utente si collega e vuole cambiare la propria password. Il campo password è memorizzato solo in Directory server . Utilizziamo la libreria di servizi di directory Novell LDAP per accedere alle informazioni da Directory Server .
Nel nostro Infrastructure Layer abbiamo un progetto in cui abbiamo implementato l'accesso al server AD. Quindi, nell'esempio sopra di cambiare la password, parleremo solo con il server AD poiché non ci sono password salvate in Application Server .
Ora la domanda è, nel mio dominio per creare un modello contenente:
ID , FirstName , LastName , Email , Phone , Username , Password , Address
o
ID , FirstName , LastName , Email
Ci sarà una schermata nell'interfaccia utente in cui è possibile modificare tutti i dettagli di Account .