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


ID, FirstName, LastName, Email

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

  • 1
    are you using Active Directory or Novell LDAP? Either way - if you just store the user's AccountID, you can look up all the rest of the user details via a call to the DS.
    – gbjbaanb
    Commented Apr 9, 2015 at 12:08
  • It's a 389 Active Directory Server and we are using the Novel.Directory.LDap third party library to communicate with it. Commented Apr 12, 2015 at 23:46
  • 1
    So not Active Directory at all, its a LDAP server. (AD is a Microsoft product). So just add ID to your domain and lookup the user as required, with caching you will get performance and single point of administration.
    – gbjbaanb
    Commented Apr 13, 2015 at 7:23
  • So basically do not create an User or Account mapping to the Application database when it comes to persistence mapping. Just use the id and look up the LDAP server, and cache it for performance. Commented Apr 13, 2015 at 23:11

2 Answers 2


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.


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.

  • That is pretty much how we do it, there is a permissions system in place on top of it, and also each user gets assigned the ID of the Instance to which they got imported to. The idea is that all User information needs to be stored on LDAP and their ID's needs to be carried over and link up in the Application database so we have some record ow who owns the product as you say. Commented May 14, 2015 at 9:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.