Domain driven design 弗农'；s实现DDD的书

我希望有人读过（弗农），因为我所有的问题都提到了它

在图6中我们可以看到，

BankingAccount

和

PayeaAccount

都代表了银行账户的基本概念BA

1.作者在第64页给出了一个出版组织的例子，在这个组织中，一本书的生命周期经历了几个阶段（提出一本书、编辑过程、该书的翻译…），在每个阶段，本书都有不同的定义

书籍的每个阶段都是在不同的有界上下文中定义的，但是所有这些不同的定义是否仍然代表了书籍的相同基本概念，就像

银行账户

和

付款人账户

代表了银行账户的相同基本概念一样

2.

a） 我理解为什么

用户

不应该存在于协作上下文（CC）中，而应该在身份和访问上下文IAC（第65页）中定义。但是，

用户

（IAC）、

主持人

（CC）、

作者

（CC）、

所有者

（CC）和

参与者

（CC）是否都代表了客户的相同基本概念

b） 如果是，CC是否包含多个模型元素（

主持人

、

作者

、

所有者

和

参与者

），这些元素代表了客户的相同基本概念，就像

BankingAccount

和

payeaccount

代表了BA的相同基本概念一样

c-如果

主持人

，

作者

。。。不代表客户的基本概念，那么它们代表什么基本概念

3.在电子商务系统中，客户一词有多种含义（第49页）：当用户浏览目录时，客户的含义与用户下订单时的含义不同

但是客户的这两个不同定义是否代表相同的基本概念，就像

银行账户
和
付款人账户
代表BA的相同基本概念一样

更新：

1.

我要说的是，他们对书的概念不同。你的建议
舞台可能根本就没有书的概念
编辑过程可能也不会使用书的概念，
他们可能会分别提到一个提案和一个草案
对一本书来说是完全不同的事情

据我所知，作者是在暗示，一本书的概念确实会在所有阶段都被建模

2.

在他的示例和您的示例中没有提到客户的概念
电子商务对客户的定义不符合
版主、作者、所有者等等。你最好做个模特
围绕您自己独特的业务需求

也许为了避免混淆，我不应该将基本概念命名为客户，而应该使用不同的名称，可能是消费者。在任何情况下，我都使用Customer这个名称来表示一个基本概念，我假设模型元素，如User、版主、Author都代表了这个概念

3.

顾客在两种不同语境中的两种不同含义
可能没有基本的基础类型。我对此表示怀疑
浏览目录你会对客户的名字感兴趣，
地址等，而在下订单时，您会感兴趣
这些东西，但对他们最近10种产品感兴趣的较少
参观了

但DDD的全部意义在于，您可以对现实的某些方面进行建模。换句话说，客户的姓名、地址和浏览历史不都是同一客户基本概念的属性吗？因此，如果团队正在处理目录，它将仅对与浏览（浏览历史…）相关的基础客户概念的那些方面/属性进行建模，而处理下单的团队将仅对与下单（地址、名称…）相关的基础客户概念的那些方面进行建模

谢谢
我读到了这本书的最后几页，读得很好。就我个人而言，我希望看到更多使用他的3个虚拟软件产品的例子

我要说的是，他们对书的概念不同。你的提案阶段可能根本没有书的概念，编辑过程也可能不会使用书的概念，他们可能会分别引用提案和草稿，这与一本书完全不同

他的例子中没有提到客户的概念，您对客户的电子商务定义不符合版主、作者、所有者等的模型。您最好围绕自己独特的业务需求对此进行建模

在两种不同的语境中，顾客的两种不同含义可能没有一个基本的基本类型。我怀疑在浏览目录时你会对客户的姓名、地址等感兴趣，而下订单时你会对这些东西感兴趣，但对他们最近参观的10种产品不太感兴趣。这两个不同上下文中的客户概念可能只共享一个唯一的客户id

我已经读到这本书的最后几页了，这本书读得很好。就我个人而言，我希望看到更多使用他的3个虚拟软件产品的例子

我要说的是，他们对书的概念不同。你的提议很可能在最后阶段