PROSAGA码农传奇-SO业务编排-无法将实际逻辑放入DDD域层

0# 甲基蓝 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  <BLOCKQUOTE>
    
      用户注册服务。用户坚持使用
  数据库，生成并保存文件（用户帐户需要），
  并发送确认电子邮件。
    
  </BLOCKQUOTE>
  
    你可以申请
    <a href="http://www.objectmentor.com/resources/articles/dip.pdf" rel="noreferrer">
      依赖倒置原则
    </A>
     这里。定义这样的域界面：
  
   <pre>
 <code>
 void ICanSendConfirmationEmail(EmailAddress address, ...)

</code>
 </pre>
  
    要么
  
   <pre>
 <code>
 void ICanNotifyUserOfSuccessfulRegistration(EmailAddress address, ...)

</code>
 </pre>
  
    接口可以由其他域类使用。使用真正的SMTP类在基础架构层中实现此接口。在应用程序启动时注入此实现。这样，您在域代码中声明了业务意图，并且您的域逻辑没有直接引用SMTP基础结构。这里的关键是界面的名称，它应该基于无所不在的语言。
  
  <BLOCKQUOTE>
    
      从数字音乐商店购买歌曲。购物车
  被清空了。购买持续存在。付款服务被呼叫。
  发送电子邮件确认。好吧，这可能与第一个例子有关。这里的问题是，谁负责编排这笔交易？
    
  </BLOCKQUOTE>
  
    使用OOP最佳实践来分配职责（GRASP和SOLID）。单元测试和重构将为您提供设计反馈。编排本身可以是其中的一部分
    的
      瘦
    </强>
     应用层。从
    <a href="https://rads.stackoverflow.com/amzn/click/com/0321125215" rel="noreferrer">
      DDD分层架构
    </A>
    ：
  
  <BLOCKQUOTE>
    
      的
        应用层
      </强>
      ：定义软件应该执行的作业并指导
  表达域对象来解决问题。这一层的任务
  负责对业务有意义或必要的
  与其他系统的应用层交互。
    
    
      该层保持薄。它不包含业务规则或
  知识，但只协调任务和代表工作
  下一层中域对象的协作。它不是
  有国家反映业务情况，但它可以有国家
  这反映了用户或程序的任务进度。
    
  </BLOCKQUOTE>
</DIV>

1# 早岁那知世事艰 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    Dimitry的回答指出了一些值得寻找的好东西。通常/轻松地发现自己处于自己的场景中，数据从db到GUI通过不同的层进行挖掘。
  
  
    我受到了Jimmy Nilsson的简单建议“价值对象，价值对象和更多价值对象”的启发。通常人们倾向于将注意力集中在名词上并将其建模为实体。当然，您经常无法找到DDD行为。动词更容易与行为相关联。一个好处是让这些动词作为Value对象出现在您的域中。
  
  
    在尝试开发域时我使用的一些指导（必须说构建一个富域需要时间，通常是几次重构迭代......）：
  
  <UL>
    <LI>
      最小化属性（获取/设置）
    </LI>
    <LI>
      尽可能多地使用值对象
    </LI>
    <LI>
      暴露尽可能少。使您的域聚合方法直观。
    </LI>
  </UL>
  
    不要忘记通过验证可以使您的域名变得丰富。只有您的域名知道如何进行购买，以及需要什么。
  
  
    当您的实体从一个州转换到另一个州（工作流程验证）时，您的域也应负责验证。
  
  
    我会举几个例子：
这是我在博客上写的一篇关于你关于贫血领域问题的文章
    <a href="http://magnusbackeus.wordpress.com/2011/05/31/preventing-anemic-domain-model-where-is-my-model-behaviour/" rel="noreferrer">
      http://magnusbackeus.wordpress.com/2011/05/31/preventing-anemic-domain-model-where-is-my-model-behaviour/
    </A>
  
  
    我还可以真正推荐Jimmy Bogard关于实体验证的博客文章，并使用Validator模式和扩展方法。它使您可以自由地验证基础结构，而不会使您的域变脏：

<a href="http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/" rel="noreferrer">
      http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/
    </A>
  
  
    我使用Udi的Domain Events非常成功。如果您认为您的服务可能失败，您也可以使它们异步。您还将它包装在事务中（使用NServiceBus框架）。
  
  
    在你的第一个例子中（现在只是集思广益，让我们的思想更多地考虑价值对象）。
  
  <OL>
    <LI>
      您的
       <code>
 MusicService.AddSubscriber(User newUser)
 </code>
       应用程序服务从具有新用户的演示者/控制器/ WCF接收呼叫。
服务已经到了
       <code>
 IUserRepository
 </code>
       和
       <code>
 IMusicServiceRepository
 </code>
       注入ctor。
    </LI>
    <LI>
      音乐服务“Spotify”通过IMusicServiceRepository加载
    </LI>
    <LI>
      实体
       <code>
 musicService.SignUp(MusicServiceSubscriber newSubsriber)
 </code>
       方法采用Value对象
       <code>
 MusicServiceSubscriber
 </code>
      。
此Value对象必须在ctor中使用User和其他必需对象
（值对象是不可变的）。在这里你也可以放置逻辑/行为，如handle subscriptionId等。
    </LI>
    <LI>
      什么是SignUp方法，它会触发域事件
       <code>
 NewSubscriberAddedToMusicService
 </code>
      。
它被抓住了
       <code>
 EventHandler HandleNewSubscriberAddedToMusicServiceEvent
 </code>
       得到了
       <code>
 IFileService
 </code>
       和
       <code>
 IEmailService
 </code>
       注入它的ctor。此处理程序的实现位于应用程序服务层中，但事件由Domain和
       <code>
 MusicService.SignUp
 </code>
      。这意味着域名处于控制之中。 Eventhandler创建文件并发送电子邮件。
    </LI>
  </醇>
  
    您可以通过事件处理程序保持用户或生成
     <code>
 MusicService.AddSubscriber(...)
 </code>
     对此的方法。两者都将通过这样做
     <code>
 IUserRepository
 </code>
     但这是一个品味问题，也许它将如何反映实际领域。
  
  
    最后......我希望你能掌握上述内容......无论如何。最重要的是开始向实体添加“动词”方法并进行协作。您还可以在域中拥有不持久的对象，它们仅用于在多个域实体之间进行调解，并且可以托管算法等。
  
</DIV>

2# 薄情 | 2019-08-31 10-32