.net core CRM的体系结构选择

在开始开发CMS、CRM或ERP之前，我想了解一下架构选择的复杂性

我发现了类似的问题： 但它似乎已经足够老了

我最近观看并阅读了几次会议，讨论了monolith vs Distributed、DDD哲学、CQR和事件驱动设计等。 考虑到每一个（我认为）的缺陷，我在架构选择上比以前更加恐慌

我发现，在网上很容易找到的所有微服务和分布式系统的例子中，令人遗憾的是，它们总是以电子商务为例（客户、订单、产品……）。对于这类示例，存在多个数据库（通常是microservice提供的NoSQL DB）。 我看到了为每个上下文保留必要数据的最低限度表示的优势（或多或少）

但是如何获得一个独特的关系型数据库呢？我真的认为我需要一个单一的关系型数据库，在一家生产CRM的公司工作过（没有机器的源代码，但是数据库的结构），我可以看到关系型数据库的重要性：对于列表、报告和咨询CRM中实体之间的链接是必要的（一个联系人可以有多个公司，反之，每个用户都有多个操作、任务，但他的每个任务也可以分配给其他用户，甚至可以链接到其他项目，如：“联系人”、“公司”、“出版物”、“日历日期”等，并且每个表中可能有大量记录（+100000行），因此索引的选择将是非常重要的，事务是无所不在的，因为将有大量并发访问数据记录）

我对自己说的是，如果我选择使用一个微服务系统，将会有很多微服务要做，因为会有很多不同的上下文，而且很可能会有一堆不同的领域模型。然后，我会有这样的印象：必须点亮一个花环的每个小灯泡，用可能有太多的进程同时运行

为了尽量做到精确，而不是全力以赴，我有两个问题要问：

我们是否可以轻松地将DDD理念与整体式系统结合起来，同时不耦合非常小的数量（因为各种原因，最终的服务应该完全分开）？ 如果是这样的话，我是否可以要求提供资源，从中我可以学到更多关于这方面的知识

我们是否必须使用大量的数据库，它是否必须是mongoDb、nosql之类的数据库？ 我可以想象答案是否定的，但我可以要求再详细阐述一下吗？或者让我看一些能给我足够清晰答案的文章

提前谢谢你

---

（可能是.NET Core，草稿在这里：）

DDD是设计CRM的完美方法。我在上一个项目（基于web的CRM）中使用了它，这正是我所需要的。事实上，如果我不使用DDD，它将无法管理。我创建的CRM（唯一的架构师和开发人员）非常复杂且非常定制。它与许多外部系统（即电子邮件服务器和电话呼叫系统）集成

您应该做的第一件事是发现系统的主要部分。这是最困难的部分，您可能第一次就弄错了。好的是，这是一个迭代过程，应该在进入生产之前稳定下来，因为这样重构就比较困难（即，您需要迁移数据，这很痛苦）。这些主要部分在DDD中称为有界上下文（BC）

我为每个业务连续性创建了一个模块。我不需要微服务，一个模块化的整体才是完美的。我使用这个模块来发现业务连续性。我注意到每个部门都有与CRM相同但也不同的需求

每个部门都有一些通用的业务连续性，如电子邮件收发、客户活动记录、任务安排、通知。所有部门的行为几乎相同

对于类似的概念，特定于部门的业务连续性具有非常不同的行为。例如，销售部门和数据处理部门对合同有不同的要求，因此我创建了两个名为

Contract

的聚合，它们共享相同的ID，但具有其他数据+行为。为了保持它们“同步”我使用了一个Saga/流程管理器。例如，当合同被激活（手动激活或在第一次付款后激活）时，就会创建一个

DataProcessingDocument

，其中包含基于合同内容的数据

另一个重要的观点是发现并尊重真相的来源。例如，收到的电子邮件的真相来源是电子邮件服务器。CRM应该在其UI中反映这一点，应该非常清楚的是，这只是对电子邮件服务器上发生的事情的延迟反映；可能收到的电子邮件不是sho由于技术原因，客户关系管理中存在wn

电子邮件草稿的真实来源是CRM，它有

电子邮件生成器

模块。如果草稿不再显示，则意味着它已被CRM用户删除

如果CRM不是事实的来源，那么代码应该很少或没有行为，数据应该基本上是不变的。在这里，您可以使用CRUD，除非您有性能问题（即数百万条），在这种情况下，您可以使用CQR

每个表中可能有很多记录（+100000行），因此索引的选择将非常重要，事务无处不在，因为将有大量并发访问数据记录）

CQRS帮助我的团队建立了一个性能+响应系统。您不必在每个模块中都使用它，只需在有大量数据和/或不同的写入和读取行为的模块中使用它即可。例如，用于记录活动