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?
我们正在使用域驱动设计开发医院管理系统。我们有像AccessManagementContext,RadiologyInformativeContext等有界限的上下文。但是我应该在哪里放置应用程序表,如Logging,Menu之类的东西?
2 个解决方案
#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.
记录和“菜单”(我假设你的意思是像web / windows菜单控件)是基础设施和实现问题。他们肯定不属于您的域名。
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:
为了让您了解如何在VS解决方案中实现DDD原则,以下是使用Onion Architecture的基本布局:
While DDD is not concerned with "solution organisation", I suspect this may be what you are asking.
虽然DDD不关心“解决方案组织”,但我怀疑这可能是你所要求的。
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).
您的有界上下文(以及所有其他与域相关的代码)将存在于域层中。日志记录将在基础架构层中实现(除非日志记录真正成为您无处不在的语言的一部分,正如SephVelut指出的那样)。菜单等将存在于Client文件夹中(例如在Web应用程序项目中)。
Regarding logging, you may want to consider looking at Domain Events if you wish to capture logs within your domain code.
关于日志记录,如果您希望捕获域代码中的日志,则可能需要考虑查看域事件。
#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.
Domain Driven Design不会试图告诉您如何安排您的架构。但它决定了应该和不应该进入你的域名的内容。记录和菜单声音不应该被允许进入AccessManagementContext和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?".
原因是语言。有人会不可避免地提到基础设施层。但这是一个架构问题,而不是域驱动的设计问题。您可能会开发一个名为HospitalRecordsSystem的有界上下文,其无处不在的语言包含了Logging的关注点。所以这是有可能的,但你必须要问“在这种有限的背景下是无处不在的语言吗?”。
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.
最后,关于建筑。在传统的分层体系结构中,您可以将基础结构问题(I / O,持久性,验证,丰满等)放在与您的域(在另一个命名空间/目录中)分离的层中,并防止域直接依赖于该层中的内容。相反,您将使用接口和依赖性反转来连接两者。
#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.
记录和“菜单”(我假设你的意思是像web / windows菜单控件)是基础设施和实现问题。他们肯定不属于您的域名。
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:
为了让您了解如何在VS解决方案中实现DDD原则,以下是使用Onion Architecture的基本布局:
While DDD is not concerned with "solution organisation", I suspect this may be what you are asking.
虽然DDD不关心“解决方案组织”,但我怀疑这可能是你所要求的。
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).
您的有界上下文(以及所有其他与域相关的代码)将存在于域层中。日志记录将在基础架构层中实现(除非日志记录真正成为您无处不在的语言的一部分,正如SephVelut指出的那样)。菜单等将存在于Client文件夹中(例如在Web应用程序项目中)。
Regarding logging, you may want to consider looking at Domain Events if you wish to capture logs within your domain code.
关于日志记录,如果您希望捕获域代码中的日志,则可能需要考虑查看域事件。
#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.
Domain Driven Design不会试图告诉您如何安排您的架构。但它决定了应该和不应该进入你的域名的内容。记录和菜单声音不应该被允许进入AccessManagementContext和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?".
原因是语言。有人会不可避免地提到基础设施层。但这是一个架构问题,而不是域驱动的设计问题。您可能会开发一个名为HospitalRecordsSystem的有界上下文,其无处不在的语言包含了Logging的关注点。所以这是有可能的,但你必须要问“在这种有限的背景下是无处不在的语言吗?”。
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.
最后,关于建筑。在传统的分层体系结构中,您可以将基础结构问题(I / O,持久性,验证,丰满等)放在与您的域(在另一个命名空间/目录中)分离的层中,并防止域直接依赖于该层中的内容。相反,您将使用接口和依赖性反转来连接两者。