标签: domain-driven-design

我有 Person 聚合，这是根聚合

public class Person 
{
    private int id;
    private readonly PersonID personID;

    private readonly string email;
    private readonly string firstName;
    private readonly string lastName;

    private readonly string username;
    private readonly string password;
    private readonly Address BillingAddress;
}

public class Currency : IValueObject<Currency>
{
    private string name;
    private string currencyCode;
    private decimal rate;
    private string displayLocale;
    private string customFormatting;
    private int displayOrder;
    private bool primaryExchangeRateCurrency;
    private bool primaryStoreCurrency;

    //<summary>
    //Gets or a value indicating whether the currency is primary …

我有一个场景，当用户请求删除时，可能会根据某种逻辑将给定实体标记为软删除或硬删除。

从 DDD 范式解决这个问题，我看到了一些问题：- DDD 建议对所有与持久性相关的东西使用 Repository 对象，其中域层仅定义这样的存储库接口（包含存储、删除、查找等典型方法）和包含存储、删除、查找等典型方法的基础设施层实际执行。考虑到，对于我这里的问题，决定是否进行软删除的逻辑属于域层，如何才能以这样的方式包含域层中的逻辑，即任何其他删除请求的安全性在实际调用 RepoImpl 上的删除操作（实际上从底层存储中删除实体）之前，层会通过此逻辑进行引导。

  即使我有一个具有类似方法的域服务void removeEntity(Entity ent)，但事实上我必须在我的存储库接口上有一个名为 的公共方法，这void remove(Entity ent)违背了目的，因为我无法强制removeEntity执行服务层的方法总是被调用，而不是remove在存储库上调用RepoImpl 需要有一个删除方法来实现实体的删除。

建议的解决方案
==============
  我有一个看起来相当做作的想法，假设 Repo 接口有一个抽象实现，它提供了一个 Final public void remove(Entity ent)，抽象实现可以执行此逻辑来确定是否它是软删除或硬删除。如果它是软删除，它实际上是设置了适当标志的实体的更新，因此它调用this.store(ent)，否则它将实体包装在DeleteEvent类中

 public class DeleteEvent<T>{
   //parametrized for Entity
  private T ent;
   DeleteEvent(T ent){
     this.entity = ent;   
}

 public T getEntity(){
   return this.entity; 
}
}

请注意，非公共的包访问构造函数，此类的对象只能从域层内构造，因此 RepoImpl 上的另一个删除方法是void removeFromStore(DeleteEvent evt) RepoImpl 从该密封器/持有者获取实体并实现删除过程。
虽然看起来可以工作但相当古怪/hacky，有没有更干净的方法来实现相同的效果？

POCO 类在领域驱动设计中有行为，例如Validate()方法，是真的吗？

我们有两种不同的微服务客户服务和订单服务.客户服务商店有关客户的信息,即名称,DOB等.订单服务将管理客户所下的订单,即订单号,成本等.这是将客户唯一参考/ ID传递给订购服务的最佳方式.

解决方案1:客户ID是客户服务中唯一的GUID.这将传递给订单服务

解决方案2:在客户服务中生成业务/人员友好的唯一代码,并将其传递给订单服务

解决方案3:还有别的吗？

我正在研究一个整体系统。它的所有代码都在一个存储库中（Web API 和后台工作人员）。系统使用 Nodejs 编写，使用 MongoDB（Mongoose）作为数据存储。我的目标是为项目的发展设定一条新路径。起初我想知道我是否可以转向基于微服务的架构。

单体架构带来了一些问题：

• 如果我的后台工作人员需要扩展。尽管只使用了其中的一小部分，但我必须将所有项目部署到服务器。
• 当代码更改时，必须重新部署所有系统。如果支付处理器在重新部署系统时调用 webhook 会怎样？

使用微服务的优势非常明显：

• 单个微服务的较小代码库。更容易推理。
• 能够为特定用例选择最适合的编程工具。
• 更容易扩展。

查看当前代码，我注意到整个项目都使用 Mongoose ODM（对象文档映射器）模型来创建、查询和更新数据库中的模型。作为一个好的编程的原则，所有这些与数据库的交互都应该被抽象出来。业务逻辑不应泄漏到其他系统层。我可以通过引入 REPOSITORY 模式（域驱动设计）来做到这一点。虽然代码仍在通过 web api 和后台工作人员共享，但这并不是一项艰巨的任务。

如果我决定将存储库提取到独立的微服务中，则会出现所有问题：

• 必须引入某种查询语言来适应复杂的搜索查询。
• 接口必须提供一种在不通过网络返回所有数据库文档的情况下迭代搜索结果（基于光标的导航）的方法。

由于项目处于早期阶段并且我是唯一的开发人员，因此转向基于微服务的架构似乎有点矫枉过正。也许我应该考虑其他方法？

将业务逻辑和与数据库的交互提取到单独的存储库中并在服务之间共享以避免服务之间的复杂通信协议？

我试图了解有关域驱动设计的详细信息，而我遇到了这个问题。我发现了很多例子：

1. 在域内定义存储库接口
2. 在其他地方定义存储库实现
3. 将存储库接口注入聚合根

另一方面，有一些示例完全违背它，并从服务中处理所有与存储库相关的工作。

我找不到权威的答案和解释：这被认为是不好的做法吗？如果是，为什么？

在微服务架构中，我正在阅读业务流程和编排的概念。选择编排和编排是否有任何指南/建议？

我正在设计一个通用的多租户身份系统（身份验证/授权），但我怀疑我是否以正确的方式设计它。

目前，设计是这样的：

AR用户参考租户和用户所属的特定组织单位。AR租户有实体组织单位列表