我最近读过有关域驱动设计的内容。最后,我遇到了我的项目应该具有的结构。结构如下:
目前,我只需要将 MyApp.Domain 和 MyApp.Application 引用到我的网站。另一方面,如果我想使用Unity作为Ioc。问题是,我是否应该参考 MyApp.Domain.Services 和 MyApp.Persistence ?为了注册类型?
由于
答案 0 :(得分:0)
您的“应用程序”如何了解您的业务对象, 如果你不告诉它,他们注册了哪个组件?
如果您正在寻找更基于“插件”的方法,那么这是一个不同的故事......
如果谈论插件(不确定Unity是如何做到的) 但我唯一的方法就是让它发挥作用(付出合理的努力) 是单位Autofac modules
您仍然需要有一个注册装配的地方 并且有类似“文件系统观察者”的东西,可以监视新的.dll并加载它们等等。
答案 1 :(得分:0)
练习DDD时的常见架构是Onion Architecture。主要是因为它比典型的n层架构有几处改进,几乎没有任何缺点。
它允许您的域和域模型成为软件的核心。域服务层通常依赖于持久层。在洋葱架构中,这将被翻转,持久层保存对域服务/模型的引用。要访问持久层,持久层中密钥类的接口保存在域层中,IoC用于连接实例化。
答案 2 :(得分:0)
First of all, why have you created six different projects? They are just a fictionary separation. If you are the only developer, do you not trust yourself? If you are more than one developer, are your communication so bad that you can't agree on in which direction dependencies go?
Good separation comes from communication and talk within a team, and not because you have created multiple projects (adding a reference is really easy).
If you want to make sure that the code keeps good quality, introduce code reviews, measure the quality with the built in analytic tools or simply write unit tests.
Therefore, project references are not the problem and never have been. Add the reference in a way that makes it easy to run and maintain the application.
If you are serious about DDD forget about the project structure. It doesn't really matter that much. Understand the methodology and what's important in DDD. Buy the blue book by Eric Evans.