标签: domain-model

我正在构建一个ORM,并试图找出每个模式的确切职责.假设我想在两个帐户之间转移资金,使用工作单元来管理单个数据库事务中的更新.以下方法是否正确？

1. 从存储库中获取它们
2. 将它们附加到我的工作单元
3. 做生意交易和提交？

例:

from = acccountRepository.find(fromAccountId);
to = accountRepository.find(toAccountId);

unitOfWork.attach(from);
unitOfWork.attach(to);    

unitOfWork.begin();
from.withdraw(amount);
to.deposit(amount);
unitOfWork.commit();

应该像在这个例子中那样独立使用工作单元和存储库,或者:

• 工作单元是否应该在内部使用存储库并且能够加载对象？
• ...或者存储库是否应在内部使用工作单元并自动附加任何已加载的实体？

欢迎所有评论!

我正在寻找一个简单的例子来说明使用丰富域模型的好处.理想情况下,我想要一个前后代码列表(应该尽可能短).

前面的代码清单应该显示使用贫血域模型解决的问题,以及许多相当程序化的服务层代码,后面的代码清单应该显示使用丰富的面向对象的域模型解决的相同问题.

理想情况下,代码清单应该是Java或Groovy,但任何相似的东西(例如C#)都可以.

我写了一个很好的简单的小域模型,其对象图如下所示:

-- Customer
    -- Name : Name
    -- Account : CustomerAccount
    -- HomeAddress : PostalAddress
    -- InvoiceAddress : PostalAddress
    -- HomePhoneNumber : TelephoneNumber
    -- WorkPhoneNumber : TelephoneNumber
    -- MobilePhoneNumber : TelephoneNumber
    -- EmailAddress : EmailAddress

这个结构与我必须使用的遗留数据库完全不一致,所以我定义了一个平面DTO,其中包含客户图中每个元素的数据 - 我在数据库中有视图和存储过程,这些允许我在这两个方向上使用这种扁平结构与数据进行交互,这一切都很好,花花公子:)

将域模型展平为DTO以进行插入/更新是直截了当的,但我遇到的问题是使用DTO并从中创建域模型...我的第一个想法是实现访问每个元素的访问者客户图,并根据需要从DTO注入值,有点像这样:

class CustomerVisitor
{
    public CustomerVisitor(CustomerDTO data) {...}

    private CustomerDTO Data;

    public void VisitCustomer(Customer customer)
    {
        customer.SomeValue = this.Data.SomeValue;
    }

    public void VisitName(Name name)
    {
        name.Title     = this.Data.NameTitle;
        name.FirstName = this.Data.NameFirstName;
        name.LastName  = this.Data.NameLastName;
    }

    // ... and so on …

最近一直在观看一些Greg Young视频,我试图理解为什么对Setters on Domain对象持否定态度.我认为在DDD中,Domain对象应该是"重"的逻辑.这个坏例子在网上是否有任何好的例子然后他们纠正它的方法？任何例子或解释都是好的.这仅适用于以CQRS方式存储的事件,还是适用于所有DDD？

我已经用PHP编程了好几年,并且过去采用了我自己的方法来处理我的应用程序中的数据.

我过去已经构建了自己的MVC,并且在php中对OOP有了合理的理解,但我知道我的实现需要一些认真的工作.

在过去,我使用了模型和数据库表之间的is-a关系.我现在知道,经过一些研究,这不是真正的最佳前进方式.据我了解,我应该创建并不真正关心底层数据库(或任何存储机制)的模型,而只关心它们的操作和数据.

从此我已经确定我可以创建模型,例如一个人,这个人对象可以有一些子(人类孩子)也是一个数组中的Person对象(使用addPerson和removePerson方法,接受一个Person对象) .

然后我可以创建一个PersonMapper,我可以使用它来获取具有特定"id"的Person,或者保存Person.

然后,这可以在查找表中查找关系数据,并为已请求的Person(如果有)创建关联的子对象,并同样将数据保存在save命令的查找表中.

这正在推动我的知识极限......

如果我想在这些级别内建造具有不同级别和不同房间的建筑物,该怎么办？如果我想在这些房间放置一些物品怎么办？

我会为建筑,水平,房间和项目创建一个课程

具有以下结构.

建筑物可以有一个或多个水平对象保持在一个数组级别可以有一个或多个房间对象保持在阵列室可以有1个或多个项目对象保持在一个数组

和更高级别映射器的每个类的映射器使用子映射器填充数组(根据顶级对象的请求或请求时的延迟加载)

这似乎紧紧地耦合了不同的物体,尽管是在一个方向上(即地板不需要在建筑物中,但建筑物可以有水平)

这是正确的做事方式吗？

在视图中我想要显示一个建筑物,可以选择一个水平,然后显示水平,选择一个房间等选项..但我可能还想显示一个像建筑物中的项目结构的树和什么他们所处的水平和空间.

我希望这是有道理的.当oop的一般概念似乎是分开的东西时,我正在努力与彼此嵌套对象的概念斗争.

如果有人可以提供帮助,那将非常有用.

在域驱动设计中,实体的一个定义特征是它具有身份.

问题:

我无法在实例创建时为实体提供唯一标识.一旦实体被持久化(此值由底层数据库提供),此标识仅由存储库提供.

此时我无法开始使用Guid值.现有数据与int主键值一起存储,我无法在实例化时生成唯一的int.

我的解决方案

• 每个实体都有一个标识值
• 一旦持久化(由数据库提供),身份仅设置为真实身份
• 在持久性之前实例化时,标识设置为默认值
• 如果标识是默认标识,则实体可通过引用进行比较
• 如果标识不是默认标识,则实体可通过标识值进行比较

代码(所有实体的抽象基类):

public abstract class Entity<IdType>
{
    private readonly IdType uniqueId;

    public IdType Id
    {
        get 
        { 
            return uniqueId; 
        }
    }

    public Entity()
    {
        uniqueId = default(IdType);
    }

    public Entity(IdType id)
    {
        if (object.Equals(id, default(IdType)))
        {
            throw new ArgumentException("The Id of a Domain Model cannot be the default value");
        }

        uniqueId = id;
    }

    public override bool Equals(object obj)
    {
        if (uniqueId.Equals(default(IdType)))
        { 
            var entity = obj …

我正在尝试为我的应用程序应用域驱动设计原则,其中包含包含数据字段和业务逻辑的丰富域模型.我读过许多DDD书籍,但似乎他们的域名模型(称为实体)非常简单.当我有一个包含10-15个数据字段的域模型时会出现问题,例如下面的那个:

class Job extends DomainModel{

    protected int id;
    protected User employer;
    protected string position;
    protected string industry;
    protected string requirements;    
    protected string responsibilities;    
    protected string benefits;
    protected int vacancy;
    protected Money salary;
    protected DateTime datePosted;
    protected DateTime dateStarting;
    protected Interval duration;   
    protected String status;
    protected float rating;  

    //business logic below 
}

如您所见,此域模型包含许多数据字段,所有这些字段都很重要,无法将其删除.我知道一个好的富域模型不应该包含setter方法,而是将其数据传递给构造函数,并使用业务逻辑来改变状态.但是,对于上面的域模型,我无法将所有内容传递给构造函数,因为它将导致构造函数方法中的15个以上参数.一个方法不应该包含超过6-7个参数,你不觉得吗？

那么我该怎么做才能处理具有大量数据字段的域模型呢？我应该尝试分解吗？如果是这样,怎么样？或者,我应该在实例化时使用Builder类或反射来初始化它的属性,这样我就不会用如此多的参数污染构造函数？谁能提出一些建议？谢谢.

我发现一个声明,即根据DDD设计的域模型不应该用作REST API(源)中的资源.

很明显,REST API是应用程序的契约,而域模型是实现的一部分,因此最好将这两个事物分开,以便域模型中的更改不会自动意味着更改REST API.

但是,我认为在小型项目(REST API只有一个消费者 - 由一个团队开发的javascript前端)的情况下,使用单独模型的好处并不能证明分离模型的成本(不同的类 - 域模型和资源表示和模型之间的映射代码).显然,域层不能引用REST特定的基础结构代码(以保持关注点分离).

域和REST模型应该分开吗？

域模型和数据模型之间有什么区别？

我一直在阅读AutoMapper,因为我在这里回答了我之前的一个问题.

它说AutoMapper会使复杂的域模型变得扁平化,但我需要的是相反的东西.我需要将我的视图模型(展平的域模型)连接到复杂的域模型,以便我可以快速将视图模型转换为域模型.

有没有类似于AutoMapper的东西采用视图模型并使其成为一个复杂的域模型？