( a)据我所知,在大多数情况下,域模型DM不包含用于创建/删除域实体的代码,而是由DM之上的层(即服务层或UI层)负责创建/删除域实体?
( b)域实体是以真实世界实体为模型的。假设被抽象的特定真实世界实体具有创建/删除其他真实世界实体的功能,那么我假设抽象这个真实世界实体的领域实体也包含创建/删除其他实体的逻辑?
class RobotDestroyerCreator
{
...
void heavyThinking()
{
...
if(...)
unitOfWork.registerDelete(robot);
...
if(...)
{
var robotNew = new Robot(...);
unitOfWork.registerNew(robotNew);
{
...
}
}谢谢
发布于 2012-10-04 19:48:28
( a) DDD没有指定域对象不应该创建域对象。域对象可以很好地创建另一个域对象。聚合负责在实体和值对象集群周围强制执行一致性边界。因此,它很可能有创建实体的行为。例如,原型销售订单聚合可以创建订单行实体(或价值对象,取决于实现)的实例。重要的是确保在定义良好的地方创建或删除域和实体。看看这篇文章,它评估域模型中的聚合创建。
( b)真实世界实体与代码中对应的抽象之间的映射从来都不是同构的。代码中的抽象受技术约束的约束,这些约束是不可忽视的。代码并不意味着是现实的同构,它仅仅意味着展示满足需求集的功能特征。现实和代码之间的相似性是我们努力简化开发过程的一个方面。换句话说,如果一个真实世界的实体创建了什么东西,它不会立即在代码中转换成相应的抽象,尽管它可能--没有硬性的规则。
发布于 2012-10-04 22:46:04
( a)域实体可能偶尔创建或删除其他实体。但是,如果要添加/删除的实体是来自同一聚合的子实体之一(在这种情况下,ORM最有可能跟踪对集合的更改并自动持久化),则通常会通过添加/删除实体从其内部集合中添加或从内部集合中移除这些更改,或者如果要创建/删除的实体是聚合根,则调用Repository。对于域对象来说,了解用户事务中的工作单元和对象的当前状态似乎不太合适--这是应用程序层的一项工作。
您还应该小心,不要将过于复杂的对象创建逻辑放在实体中--从不同的部分组装复杂的对象,而不是属于一个工厂。
( b)代码中的确有优雅之处,它反映了现实世界的概念是如何发展的--它非常流畅、可读性强、易于理解。此外,DDD确实鼓励我们根据领域的实际概念命名代码结构。
然而,它也告诉我们,模型和无处不在的语言应该是领域专家/开发人员协作的结果。这并不是说你可以把域名倒在键盘上,然后看着你的域对象神奇地书写自己。抽象不仅仅是从真实到代码的翻译,名词变成类,动词变成方法,更重要的是。在业务需求和技术需求满足的地方,需要某种类型的转换过程。在此过程中,存在于现实世界中的一些对象或对象之间的关系将被保留,而另一些则不会--因为它们在代码中无法方便地表示,或者因为它们挫败了良好的软件实践,例如关注点分离、内聚、低耦合等等。新的域对象也会出现,可能是那些在现实世界中没有物化的对象。
因此,电脑版本的现实世界领域的问题或活动是另一种动物,没有规则允许你事先告诉是否会有一个类别的这个商业行为者或一个方法的商业概念。您可以确定的是,它们的名字可能会在代码的某个地方找到。
https://softwareengineering.stackexchange.com/questions/167479
复制相似问题