Take the 2-minute tour ×

If I am developing an application using DDD, where do the infrastrucure and behavior components go? For example, user management, user specific configuration, permissions, application menuing, etc.

These components really have nothing to do with the business requirements being fullfilled by my domain, but they are still required elements of my application. Many of them also require persistance.

share|improve this question
I'll tell you where they don't belong: The domain. –  Oded Sep 9 '11 at 20:53
add comment

2 Answers

up vote 1 down vote accepted

It's pretty normal to have non-domain components along with the domain in your project - after all not everything is business domain oriented. Where they belong actually depends on how you structure your solution. In most cases I tend to follow Onion Architecture, so all of my logic is provided by Application Services, regardless if it's domain or non-domain oriented.

share|improve this answer
Can I assume correctly that these application infrastructure components, though accessed through the same Application Services that the domain related components are, do not follow DDD principles? As far as being structured with an Aggregate Root, Entity and Value objects? –  EkoostikMartin Sep 13 '11 at 14:31
Yes, that is exactly what I meant. Of course with the exception of scenarios when these are actually business domain concerns - but that's pretty rare. –  kstaruch Sep 14 '11 at 10:25
add comment

Well if you find that your usecases rarely demands information from your core domain joined with application specific, you can probably split that into a separate database. Access this information through Application Service layer, since this layer is suppose to serve your application needs. If that includes user profile persistence etc, that's fine.

But you remember that if you got infrastructural failure and you want to do a rollback with some transaction logs or database backups, you'd probably want all persisted data be roll-backed. So then it's easier to have these domains share a database. Pros and cons - always compromise...

If I know that this application would have minor interaction with it's environment, I would put this in one database and let the application service layer interact with clients.

If I know that there will be several applications/clients I may consider to split database so that Webb application user specifics are stored in separate database. Very hard to say, since I have no overview of all the requirements.


share|improve this answer
add comment

Your Answer


