我希望有人读过Implementing DDD（弗农），因为我所有的问题都引用了它
在article我们可以从图6 看到，BankingAccount和PayeeAccount代表银行账户的相同基本概念 BA
1。在第64页上，作者提供了一个发布组织的示例，其中一本书的生命周期经历了几个阶段（提出一本书，编辑过程，书的翻译 ...）并且在每个阶段，本书都有不同的定义。
本书的每个阶段都是在不同的 Bounded Context 中定义的，但所有这些不同的定义仍然代表 Book 的底层概念 strong>，就像BankingAccount和PayeeAccount代表 BA 的基础概念一样？
2
a）我理解为什么{<1}}不应存在于协作上下文（CC）中，而应该在身份和访问上下文 IAC中定义（第65页）。但是，User（IAC），User（CC），Moderator（CC），Author（CC）和Owner（CC）代表所有代表客户的相同基本概念？
b）如果是，则CC不包含多个模型元素（Participant，Moderator，Author和Owner）代表客户的基础概念，就像Participant和BankingAccount代表相同的基础概念一样a BA ？
c - 如果PayeeAccount，Moderator ...不代表客户的基础概念，那么底层概念它们代表什么？
3. 在电子商务系统中，术语客户具有多种含义（第49页）：当用户浏览< strong>目录，客户与用户放置订单时的含义不同。
但客户的这两个不同定义代表相同的基础概念，就像Author和BankingAccount代表相同< em> BA的基本概念
更新
1
我会说他们没有相同的书概念。你的提议 阶段可能根本没有书的概念和 编辑过程也许不会使用书的概念， 他们可能会分别提到提案和草案 与书完全不同。
据我所知，作者暗示一本书的概念确实会在所有阶段建模？
2
在他的例子和你的例子中没有提到客户的概念 客户的电子商务定义不适合该模型 版主，作者，所有者等。你最好对这个进行建模 围绕您自己独特的业务需求。
也许为了避免混淆，而不是命名基础概念客户我应该使用不同的名称，也许是消费者。在任何情况下，我都使用Customer这个名称作为基础概念，我假设模型元素如User，Moderator，Author都代表。
第3
两种不同背景下客户的两种不同含义 可能没有基本的底层类型。我怀疑这期间 浏览您对客户名称感兴趣的目录， 地址等，而在下订单时你会感兴趣 这些东西，但对他们最近10个产品的兴趣不大 访问了。
但DDD的重点在于你对现实的选定方面进行建模。换句话说，客户的基础概念的所有属性都不是客户的名称，地址和浏览历史记录吗？因此，如果团队正在处理目录，它将仅模拟与浏览相关的基础客户概念的那些方面/属性（浏览历史记录...... ），在下订单的团队中，只会模拟与下订单（地址，名称......）相关的基础客户概念的那些方面？
感谢
答案 0 :(得分：1)
我正在读这本书的最后几页，这是一本很好的阅读。就个人而言，我希望看到更多使用他的3个虚构软件产品的例子。
我会说他们没有相同的概念。你的提案阶段可能根本没有书的概念，编辑过程也许不会使用书的概念，他们可能会提到一个提案和一个分别草稿，这对于一本书来说是完全不同的东西。
在他的例子中没有提到客户的概念，并且您的客户的电子商务定义不适合版主，作者，所有者等的模型。您最好围绕您的模型进行建模拥有独特的业务需求。
两种不同背景下客户的两种不同含义可能不会有基本的基础类型。我怀疑在浏览目录时你会对客户的名字，地址等感兴趣，而在下订单时你会对这些东西感兴趣，但对他们访问的最后10个产品不感兴趣。客户的两个不同上下文概念可能只共享唯一的客户ID。