我有一个持久性无知域模型,它使用抽象存储库来加载域对象.我的存储库(数据访问层(DAL))的具体实现使用实体框架从sql server数据库中获取数据.数据库对其许多varchar列具有长度限制.现在假设我有以下域类:
public class Case
{
public Case(int id, string text)
{
this.Id = id;
this.Text = text;
}
public int Id { get; private set; }
public string Text { get; set; }
}
Run Code Online (Sandbox Code Playgroud)
并且抽象存储库定义如下:
public abstract class CaseRepository
{
public abstract void CreateCase(Case item);
public abstract Case GetCaseById(int id);
}
Run Code Online (Sandbox Code Playgroud)
[text]sqlserver中表的列定义为nvarchar(100)
现在我知道我提到我的域类(Case)是持久性无知的,但我觉得它允许text参数的值最终无法通过我的具体存储库实现保存是错误的,因为实体框架将抛出异常时当text属性超过100个字符时,将属性分配给实体框架生成的类.所以我决定在域模型中检查这个约束,因为这允许我在尝试将数据传递给DAL之前检查数据有效性,从而使错误报告更加中心到域对象.我想你可以说我可以在我的构造函数和属性setter中检查约束,但由于我有数百个类都有类似的约束,我想要一个更通用的方法来解决问题
现在,我想出的是一个叫做的类ConstrainedString,定义如下:
public abstract class ConstrainedString
{
private string textValue;
public ConstrainedString(uint maxLength, string textValue)
{
if …Run Code Online (Sandbox Code Playgroud) 假设我有一个从C#类创建的域模型,如下所示:
public class MyClass
{
public string MyProperty { get; set; }
}
Run Code Online (Sandbox Code Playgroud)
与模型一起,我为IoC定义了存储库接口类.
现在,我正在尝试使用LINQ映射将此POCO域模型转换为一组实体类.(这篇approch在我正在阅读MVC的书中被推荐.)在上面的例子中,这很容易做到一些属性,而不会影响类的"普通旧":
[Table]
public class MyClass
{
[Column]
public string MyProperty { get; set; }
}
Run Code Online (Sandbox Code Playgroud)
当我开始映射关联,更改修改等时,问题就出现了.似乎我正在迅速破坏域模型的原始概念,而只是简单地创建一组LINQ-to-SQL类.我错过了什么吗?这些类仍然是业务逻辑的正确位置吗?我是否仍然可以并且应该继续从非LINQ,非数据库源加载数据到这些类中?
谢谢
我有一个域模型类型。它的众多属性之一需要 ITranslationService 来提供将其返回值转换为适当语言的能力。
我是否应该将 ITranslationService 注入域模型类型的构造函数中(因此必须在实例化类型的任何地方进行更改,并且在通过 NhIbernate 检索时必须关注初始化),即使它被类型的一小部分使用(一个许多属性);或者我可以使用另一种功能模式吗?
有没有人有相关的经验可以分享?
假设我有一个复杂的系统,那里有大量的树木.简单的想法是员工/经理关系,许多员工向一位经理报告.现在除了经理之外,还有能够代表经理行事的支持人员可以操纵经理的员工.
在CQRS系统中,您如何为"编辑员工"的假设操作建模消息,其中操作的调用者是支持人员.只有当经理安全关系中的工作人员对其领域的员工采取行动时,该行动才能成功.
验证此安全性将涉及查询数据库以验证被修改的人确实在该经理的员工链内.
这个查询会在哪里发生?在发起"编辑员工"消息之前?
如果在发起消息之前对数据进行了前期验证,则在最终一致的系统中,假设在处理"编辑员工"消息之前,已发生单独的操作,该操作将删除用户完成"编辑员工"操作的权限.如果命令处理程序未验证该消息的安全性问题,则即使用户不再具有执行该消息的权限,该消息仍将成功.
这似乎意味着双边验证,类似于UI验证和服务器端验证将是最佳的行动方案.然而,完成该验证的方法似乎违反了CQRS的关键原则.
在使用CQRS时,必须处理这些和其他类似的横切问题时,哪种方法最好?
我正在尝试在具有大量业务逻辑的项目上有效地使用DDD和Doctrine2。
这对我来说是很新的,我正在阅读许多文章和代码示例,以了解DDD的主要原理和实践。
我知道我们需要将域对象与与系统相关的其他概念分离,即在分层体系结构中,“域层”必须与其他层隔离,例如持久层/服务(Doctrine2对我来说)。
但是有一件事对我来说很难理解:在带有doctrine2的ddd的几个代码示例中,域实体中的聚合是使用Doctrine ArrayCollection管理的,我发现了这种代码:
namespace Acme\Domain\Model\Users;
use Doctrine\Common\Collections\ArrayCollection;
class User{
//...
/**
* Collection of Roles
*
* @var Collection of Roles
*/
protected $roles;
/**
* Constructor.
*/
public function __construct()
{
$this->createdAt = new \DateTime();
$this->roles = new ArrayCollection();
}
public function getRoles()
{
return $this->roles;
}
//...
}
Run Code Online (Sandbox Code Playgroud)
对我而言,此实现在域模型和持久性服务 Doctrine2 之间建立了高度的耦合。
另一方面,如果我认为DDD实体和Doctrine实体类是分离的,那么层/类将很多。你怎么看 ?有更好的方法来避免/处理此问题吗?
我有一个值对象LoginAuth,其中包含User我的辅助登录系统的身份验证数据。
对于每个登录User,都可以选择是否选择辅助登录。因此User实体并不保存LoginAuth值对象,而是LoginAuth值对象包含User它所属的实体。
由于我的数据库已标准化,因此我将此值对象存储在一个单独的表中,其中 是user_id主键(以确保唯一性)。
正如您所看到的,我的值对象并不存在于实体内部,而是独立存在,但它确实包含它所属的实体。我的问题是:
价值对象可以在不存在于实体内部的情况下存在吗?
也许这需要是一个实体?
每个都LoginAuth应该是唯一的(每个 只User允许有一个唯一LoginAuth),因此不会有任何与此 VO 相同的内容。
注意:我的域不包含此登录系统的应用逻辑。只是它应该处理的数据。它的应用逻辑驻留在我的模型层的应用层中。
试图实现的目标是创建一个如下所示的类。
public class Purse
{
public decimal AvaliableBalance { get; protected set; }
public decimal PendingBalance { get; protected set; }
public decimal TotalBalance { get; protected set; }
}
Run Code Online (Sandbox Code Playgroud)
但是,我想知道实体框架是否能够填充此类。如果是这样,怎么办?
基本上,要完成的工作是在代码端直接限制对这些属性的写操作,但是我希望Entity Framework能够写这些属性。我想通过一个唯一的目的是通过写一个方法来公开这些属性的设置方法值(即:经过一些处理后)。
我有以下域建模问题,我似乎最终要么跨越一致性边界或创建一个巨大的聚合.有人可以帮我分手吗?
有两种作业类型JobA,JobB.JobA由任务组成TaskA.JobB由任务组成TaskB.JobA并且JobB是无关的.它们之间唯一共同点是它们都需要设备资源.我本来想创建5个聚合根,它们可以互相JobA引用- 将参考TaskA等等.

我可以将一份工作及其任务集中在一起.这是以引入其他开销为代价的,因为任务本身就是复杂的生物.但是,以下约束阻止我使用任一模型.
TaskA和JobA).只有一个聚合会将所有交易放在边界内,但这会使得总量不可能大.是否有一个隐藏在这一切中的不同模型我错过了?
domain-driven-design transactions aggregateroot domain-model
我发现很难决定某些东西应该是域名还是应用程序的一部分.
通过这个答案阅读有助于很多概念,如授权,但我仍然发现自己正在努力与其他事情.
为了说明我的困惑,请考虑发表评论的案例.以下是在发布评论之前需要执行的操作.我在括号中指出我认为这个功能应该去哪里.
我无法确定检查垃圾评论是否是域关注或应用程序,同样适用于限制.从我的观点来看,这些问题对我来说都很重要,必须存在.但同样适用于授权,我们知道它不应该在域中.
如果我在域服务和应用程序服务之间拆分这些问题,那么我觉得我的域名没有完全执行,实际上依赖于应用程序进行事先检查.在这种情况下,重点是什么,为什么我不应该在应用程序中全部完成以减少混淆?
我目前的设置是这样的:
Controller ->
App.CommentingService.Comment() ->
Domain.CommentingService.Comment()
如果有人可以通过所有必需的步骤来创建注释并将其分配到正确的层,从而给出一些推理,那将会很有帮助.
假设有一个用户有任务的场景.每个用户可以是任务的观察者或工作者.
此外,工人可以提交他在给定任务上工作的时间.
下图是否正确?我已经浏览过域模型,但我还没有看到有两个关联(作品,手表).可以接受吗?
编辑:这个场景怎么样?用户可以向其他用户提出要约.可能的建模方法如下图所示.
但是,在该图中,用户似乎可以向自己提出要约.是否有可能对某些约束进行建模,或者是否在开发线下进一步处理?
domain-model ×10
c# ×3
cqrs ×2
constraints ×1
doctrine-orm ×1
entity ×1
linq-to-sql ×1
messaging ×1
poco ×1
security ×1
string ×1
transactions ×1
uml ×1