DDD using an ORM and a Active Directory Server for Persistence

Question

With Domain Driven Design one would model out the domain. One would then use an ORM of some sort to take care of the persistence. Say you have a Product entity which has a Name, SKU and an Owner. This will be modelled and when a new Product gets created you need to pass in all 3 fields as parameters into the constructor.

The above will be persisted by Fluent NHibernate using a Postgresql Database.

The Owner of the product is of type Account. The Account is an entity which holds ID, FirstName, LastName, Email, Phone, Username, Password and Address.

The Account needs to be persisted in two databases. It needs to persisted into the Application Database (Postgresql Server) so that there can be a link between Product and Account. However, it also needs to be saved on the 389 Active Directory server. This AD server holds all user records and their information.

I don’t want to duplicate all the data which is stored on the Active Directory server and save it to the Application Server. On the Application Server I want to save FirstName, LastName, Email and the ID.

If a user chooses to change their Account details, this will then update the Active Directory Server and the fields stored in the Application Server.

E.G. A user logs on and wants to change their password. The password field is only stored in the Directory server. We use the Novell LDAP directory services library to access the information from the Directory Server.

In in our Infrastructure Layer we have a project where we implemented access to the AD server. So in the example above of changing password, we will only be talking to the AD server as there is no password saved in the Application Server.

Now the question is, in my domain to I create a model containing:

ID, FirstName, LastName, Email, Phone, Username, Password, Address

Or

ID, FirstName, LastName, Email

There will be a screen in the UI where one can change all Account details.

Answer 1

I have done some more research in domain driven development.

Bounded Contexts seemed to help me solve this problem.

I started modeling out the system and not caring about the persistence, as you should do with DDD.

In the infrastructure level, I have separated out where data should be saved.

The data that is related to the User and Organisation for example, will be saved to LDAP where as all the other data will be saved to the application database.

We basically wrote a Service which the application services can use.

Answer 2

I think you are treading on dangerous ground here.

On one hand you have an LDAP authentication system which also has user name, and extra info in it.

On the other you have a domain concept of a product owner.

Its tempting to see the LDAP service as just a repository for product owners, but I dont think it really is. you will have all sorts of users in AD, only some of which will be product owners in your app and in the future you may have product owners in your app which are not in AD. (ie. someone leaves the company and is removed from AD?)

I would duplicate the data and have an extra AuthenticatedBy set of models to link product owners to your LDAP/AD system.