我正在考虑为我的ASP.NETMVC网站应用CQS,但这是一件非常简单的事情。我不是指CQRS,因为我想对查询和命令部分使用相同的数据源,因此我不需要事件溯源和其他更复杂的模式。所以,我的想法是:查询和命令部分使用同一个数据库对于查询部分,通过EntityFramework和WCF数据服务暴露数据库View,从而将特定的View返回给客户端,查询数据变得非常容易对于命令部分,使用EntityFramework和单向WCF服务公开数据库表,并使用DDD原则。我主要想实现的是:由单向服务操作执行并由丰富的领域模型处理的简单命令,客户端只需传递执行命令真正需要的数据针对客户的特定UI设计的简
问这个问题的原因是我一直想知道如何将所有这些不同的概念拼接在一起。有很多关于DDD、依赖注入(inject)、CQRS、SOA、MVC的示例和讨论,但关于如何以灵活的方式将它们组合在一起的示例并不多。我的目标:开发无需修改或无需修改即可独立运行的模块更改或重新设计UI应该尽可能简单(即UI应该尽可能少做,并且“愚蠢”使用记录在案的模式和原则为了更容易提出具体问题,主要架构现在看起来像这样:该示例显示了如何向员工添加备注。员工管理是一种有界上下文。员工有几个属性,其中一个ICollection.绑定(bind)上下文在我的理解中,分离代码的逻辑位置。每个BC都是一个模块。大多数时候,我发
假设我有publicclassProduct:Entity{publicIListItems{get;set;}}假设我想找到一个最大的项目...我可以添加方法Product.GetMaxItemSmth()并使用Linq(fromiinItemsselecti.smth).Max())或使用手动循环或其他方式。现在,问题是这会将整个集合加载到内存中。正确的解决方案是进行特定的数据库查询,但域实体无权访问存储库,对吧?所以要么我做productRepository.GetMaxItemSmth(product)(这很丑,不是吗?),或者即使实体可以访问存储库,我也使用来自实体的IPro
我的意思是-在物理上,在代码中。命名、命名空间、文件夹、程序集、数据库的组织。限界上下文应该如何交互?例如,随意使用经典e-commercebusinessdomain. 最佳答案 我会说'这取决于'有时将您的BC实体映射到同一个数据库就足够了,有时您的BC可能有不同的数据库。IMO,电子商务可能更像是一个BC而不是一个完整的领域。我在一家销售食品的整体销售代理处呆了太多时间。所以域是“wholesales”,限界上下文是,inventory,purchase,sales,invoicing,productcatalogue和e-c
在DDD方法中,值对象是否应该持有对实体的引用?编辑@德米特里:这可能是我的情况。在这里,我附上了类图,其中Account包含对IInvoiceable项目集合的引用。我将Tenant视为实体,但它只拥有1个帐户,我认为Account不需要身份。它是Tenant的一部分。还是我应该将其视为实体?对我来说这没有意义。 最佳答案 是的,可以。这将是一个相对模糊的案例,但DDD允许它并且它可能很有用。来自DDDbookbyEricEvans:VALUEOBJECTScanevenreferenceENTITIES.Forexample,i
我正在学习DDD,并且遇到了“值对象”应该是不可变的声明。我知道这意味着对象状态在创建后不应更改。这对我来说是一种新的思维方式,但在很多情况下都是有道理的。好的,所以我开始创建不可变的值对象。我确保他们将整个状态作为构造函数的参数,我不添加属性setter,并确保不允许任何方法修改内容(仅返回新实例)。但现在我想创建这个包含8个不同数值的值对象。如果我创建一个具有8个数字参数的构造函数,我觉得它不会很容易使用,或者更确切地说-在传递数字时很容易出错。这不是好的设计。所以问题是:是否有任何其他方法可以使我的不可变对象(immutable对象)更好......,可以在C#中完成任何魔术来克
关闭。这个问题是opinion-based.它目前不接受答案。想要改进这个问题?更新问题,以便editingthispost可以用事实和引用来回答它.关闭9年前。社区在4个月前审查了是否重新打开此问题,然后将其关闭:原始关闭原因未解决Improvethisquestion首先,我想澄清一下,我是领域驱动设计的新手,我问这个问题是因为我读过一些叫做贫血领域模型的东西。大多数时候我在使用Repository模式时会看到以下内容。我们有一个通用存储库我们的模型只包含一组公共(public)属性,但不包含任何方法(因此根据DDD的定义,它变成了贫血领域模型),因为这里的存储库类处理该实体或模型
我正在使用DDD原则制作应用程序。在尽可能多地考虑所有事情之后,我决定开始制作我的限界上下文。我还没有设置最终结构,但截至目前,我的应用程序将包含以下限界上下文:员工管理采购归档报告我希望它尽可能地可插拔,这样我就可以分别开发和维护它们。他们可能会公开WCF或WebAPI以与它们交互。我将使用UdiDahansimplementationofasimpleCQRSpattern.我不想一直使用事件源、消息总线等,因为这不是一个高度协作的应用程序(少于1000个用户,他们不太可能编辑相同的小数据集),这会增加了很多不必要的复杂性。所以问题:Theemployeeanddepartment
我有一个根对象,它有一个集合属性。例如:IhaveaShelfobjectthathasBooks.//NowpublicclassShelf{publicICollectionBooks{get;set;}}//WantpublicclassShelf{publicIQueryableBooks{get;set;}}我想要完成的是返回一个IQueryable集合,这样我就可以直接从父集合运行分页和过滤。varshelf=shelfRepository.Get(1);varfiltered=frombookinshelf.Bookswherebook.Name=="TheGreatGa
在阅读了好书“FrameworkDesignGuidelines”(2008年11月第2版)的附录A“C#编码风格约定”之后,我对Microsoft内部使用/推荐的编码风格感到很困惑。博客条目ABriefHistoryOfC#Style声明:Infact,thedifferencesbetweenthe"StyleCopstyle"andthe"FrameworkDesignGuidelinesstyle"arerelativelyminor在我看来,差异非常明显。StyleCop说左大括号应该在单独的一行上,框架设计指南说它应该在开头语句之后。StyleCop说所有关键字后面都要跟一