我希望有人已经阅读了实现 DDD（弗农），因为我所有的问题都参考了它
在文章中，我们可以从图 6中看到，两者都BankingAccount代表PayeeAccount了银行账户 BA的相同基本概念
1.在第 64 页，作者举了一个出版组织的例子，一本书的生命周期经历了几个阶段（提出一本书、编辑过程、翻译这本书……），在每个阶段这本书有不同的定义。
这本书的每个阶段都在不同的限界上下文中定义，但是所有这些不同的定义是否仍然代表一本书的相同基本概念，就像两者一样并且代表一个BA的相同基本概念？BankingAccountPayeeAccount
2.
a) 我理解为什么User不应该存在于协作上下文(CC) 中，而是应该在身份和访问上下文IAC 中定义（第 65 页）。但是，User(IAC)、Moderator(CC)、Author(CC)、Owner(CC) 和Participant(CC) 是否都代表了相同的Customer的基本概念？
b) 如果是，那么 CC 是否包含多个模型元素（Moderator、、和） Author，它们代表相同的Customer的基本概念，就像两者一样并代表BA的相同基本概念？OwnerParticipantBankingAccountPayeeAccount
c - 如果Moderator, Author... 不代表Customer的基本概念， 那么它们代表什么基本概念？
3.在电子商务系统中，客户一词有多种含义（第 49 页）：当用户浏览目录时，客户与用户下订单时的含义不同。
但是，这两种不同的Customer定义是否代表相同的基本概念，就像两者一样BankingAccount并且PayeeAccount代表BA的相同基本概念？
更新：
1.
我想说他们对书的概念不同。你的提案阶段可能根本不会有书的概念，编辑过程也可能不会使用书的概念，他们可能分别指的是提案和草稿，这与一本书完全不同。
据我所知，作者是在暗示一本书的概念确实会在所有阶段都被建模？
2.
他的示例中没有提到客户的概念，并且您对客户的电子商务定义不适合版主、作者、所有者等模型。您最好围绕自己独特的业务需求进行建模。
或许为了避免混淆，与其将基本概念命名为客户，我应该为它使用不同的名称，也许是消费者。在任何情况下，我都使用客户这个名称来表示一个基本概念，我假设用户、主持人、作者等模型元素都代表了这个概念。
3.
两种不同上下文中客户的两种不同含义可能不会具有基本的底层类型。我怀疑在浏览目录时你会对客户的姓名、地址等感兴趣，而在下订单时你会对这些东西感兴趣，但对他们最近访问的 10 件产品不太感兴趣。
但 DDD 的全部意义在于您对现实的选定方面进行建模。换句话说，客户的姓名、地址和它的浏览历史不都是客户相同基本概念的所有属性吗？因此，如果团队正在处理Catalog，它将仅对与浏览相关的潜在客户概念的那些方面/属性进行建模（浏览历史......），而处理下订单的团队将仅对那些方面进行建模与下订单相关的潜在客户概念（地址、姓名……）？
谢谢