Where should I put application specific thing while modelling using domain driven design?

Question

We are developing a Hospital management system using domain driven design. We have bounded context like AccessManagementContext, RadiologyInformativeContext, etc. . But where should I place application table like Logging, Menu like things?

Answer 1

Logging and "Menus" (I assume you mean like a web/windows menu control) are infrastructural and implementation concerns. They are most certainly not part of your domain.

To give you an idea of how you can implement DDD principles in a VS solution, here is a basic layout based using the Onion Architecture:

While DDD is not concerned with "solution organisation", I suspect this may be what you are asking.

Your bounded contexts (and all other domain-related code) will exist in the Domain layers. Logging will be implemented in the Infrastructure layer (unless logging is truly part of your ubiquitous language, as SephVelut pointed out). Menus and such will exist in the Client folder (say in a Web Application project).

Regarding logging, you may want to consider looking at Domain Events if you wish to capture logs within your domain code.

Answer 2

Domain Driven Design doesn't try to tell you how to arrange your architecture. It does however dictate what should and shouldn't go into your domain. Logging and Menu sound like they should NOT be allowed into your AccessManagementContext and RadiologyInformativeContext.

The reasons why is language. Someone will inevitably mention infrastructure layer. But this is an architectural issue, not a domain driven design issue. It is possible that you could develop a bounded context called HospitalRecordsSystem who's ubiquitous language envelopes the concerns of Logging. So it is possible, but you have to ask "is the ubiquitous language spoken within this bounded context?".

Finally, concerning architecture. In a traditional layered architecture you would place infrastructure concerns (I/O, Persistence, Validation, Plumping etc) in a layer separated from your domain (in another namespace/directory) and prevent the domain from directly depending on things from that layer. Instead you would use interfaces along with dependency inversion to connect the two.