COLA 5.0 数据交互个人理解图

[felix9ia]

刚入坑的时候，有很多数据交互的疑惑，通过 example 也没能理解得到。现在自己用的顺手了，所以整理了一张图，和大家交流交流

关于类后缀相关的命名的问题，请参考官方示例 https://github.com/alibaba/COLA/tree/master/cola-samples/craftsman

[caizi12]

另外之前你提到阿里开发手册那里DO 是Data Object，那是因为这个手册出现之前阿里内部大部分应用都是Spring MVC架构，在这个架构下用DO没问题，后来DDD流行了，DO用来表示infra层就不适合了。
现在ddd架构里国内都不会用DO来表示infra层的模型，DO都是指的是Domain Object，Infra层统一用PO，你可以网上搜搜看。

[caizi12]

谁告诉你DO 是 Domain Object？从你的图上来看，在到达 Domain 层之前，我也没看到你提前把 DTO 转成 Domain 层 Entity，这意味着你的 Domain 层还是贫血模式。不能让Domain的上层去调用充血后的方法。比如下面的 init 方法。 ....

1、在所有的DDD书里面都会有Domain Object，唯独没有Data Object。
2、在到达Domain层之前是App层，DTO转Entity是在App层的代码里实现。
3、我这边用的是贫血模型，额外加了一个域服务来处理域内一些业务逻辑，贫血模型更适合mvc架构转过来的新人，理解成本和上手难度更底，阿里内部不少团队也都用的贫血模型。

[felix9ia]

谁告诉你DO 是 Domain Object？从你的图上来看，在到达 Domain 层之前，我也没看到你提前把 DTO 转成 Domain 层 Entity，这意味着你的 Domain 层还是贫血模式。不能让Domain的上层去调用充血后的方法。比如下面的 init 方法。 ....

1、在所有的DDD书里面都会有Domain Object，唯独没有Data Object。 2、在到达Domain层之前是App层，DTO转Entity是在App层的代码里实现。 3、我这边用的是贫血模型，额外加了一个域服务来处理域内一些业务逻辑，贫血模型更适合mvc架构转过来的新人，理解成本和上手难度更底，阿里内部不少团队也都用的贫血模型。

我都告诉你了，DO，PO，VO，DTO，POJO 这套标准的是阿里的开发规范，具体看这里：https://www.cnblogs.com/EasonJim/p/7967999.html。

或者这里

https://github.com/chjw8016/alibaba-java-style-guide/blob/master/c4/s1.md

你如果没有看过这块，你先去看一下再来回复我。
再者：阿里对DO 的定义是：
DO（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
下次回复首先回答我以下问题：

1. 你是否看过了阿里开发规范中的定义？
2. 你解释一下什么是一一对应？聚合后的Doamin Object 可以与数据库表结构一一对应吗？
3. 告诉我COLA的哪个层是或包含了 DAO层？通过DAO层向上是什么意思？
4. 你非得说DO 是 Domain Object，那就把你从哪本书看来可以这样缩写引用到你的回复中。
5. 你的 Domain 层是否依赖了 infra 层？

总结：我想说的是，沟通的前提是大家对概念都有统一的认知，这个认知来自于出处的定义。你不能指望你公司新入职的人强行让人家把 DO 理解成 Domain Object。至于团队是否选择充血确实不重要，但是要确保 Domain 能随时参与到框架中，前提是 Domain 层要保证其独立性，不依赖任何其他层

[youngledo]

另外之前你提到阿里开发手册那里DO 是Data Object，那是因为这个手册出现之前阿里内部大部分应用都是Spring MVC架构，在这个架构下用DO没问题，后来DDD流行了，DO用来表示infra层就不适合了。 现在ddd架构里国内都不会用DO来表示infra层的模型，DO都是指的是Domain Object，Infra层统一用PO，你可以网上搜搜看。

我觉得用DO作为Data Object是没问题的，反而用PO不合适。你看Spring Data XXX都是基于Data来的，也就是把业务产生后的结果是作为数据（data）。虽然Spring没有提供一套完整的DDD框架，但是每个组件都是按照DDD思想设计的，这一点在https://spring.io/projects/spring-modulith尤其如此。只不过因为这个规范没有统一才会导致这样。我估计，随着发展，Spring也会有DDD相关的框架。

此外，千万不要把“领域对象”（也就是所谓的Domain Object）简单理解成就是一个简单对象（POJO）。“领域对象”更确切的说，是领域（业务）模型，是承载业务的，因此以后请称之为领域模型，模型是不加任何后缀的。并且是禁止用lombok设置@Data注解的，只能通过构造器或者构造方法赋值。

[youngledo]

谁告诉你DO 是 Domain Object？从你的图上来看，在到达 Domain 层之前，我也没看到你提前把 DTO 转成 Domain 层 Entity，这意味着你的 Domain 层还是贫血模式。不能让Domain的上层去调用充血后的方法。比如下面的 init 方法。 ....

1、在所有的DDD书里面都会有Domain Object，唯独没有Data Object。 2、在到达Domain层之前是App层，DTO转Entity是在App层的代码里实现。 3、我这边用的是贫血模型，额外加了一个域服务来处理域内一些业务逻辑，贫血模型更适合mvc架构转过来的新人，理解成本和上手难度更底，阿里内部不少团队也都用的贫血模型。

我都告诉你了，DO，PO，VO，DTO，POJO 这套标准的是阿里的开发规范，具体看这里：https://www.cnblogs.com/EasonJim/p/7967999.html。

或者这里

https://github.com/chjw8016/alibaba-java-style-guide/blob/master/c4/s1.md

你如果没有看过这块，你先去看一下再来回复我。 再者：阿里对DO 的定义是： DO（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。 下次回复首先回答我以下问题：

1. 你是否看过了阿里开发规范中的定义？
2. 你解释一下什么是一一对应？聚合后的Doamin Object 可以与数据库表结构一一对应吗？
3. 告诉我COLA的哪个层是或包含了 DAO层？通过DAO层向上是什么意思？
4. 你非得说DO 是 Domain Object，那就把你从哪本书看来可以这样缩写引用到你的回复中。
5. 你的 Domain 层是否依赖了 infra 层？

总结：我想说的是，沟通的前提是大家对概念都有统一的认知，这个认知来自于出处的定义。你不能指望你公司新入职的人强行让人家把 DO 理解成 Domain Object。至于团队是否选择充血确实不重要，但是要确保 Domain 能随时参与到框架中，前提是 Domain 层要保证其独立性，不依赖任何其他层

我认同！

[caizi12]

谁告诉你DO 是 Domain Object？从你的图上来看，在到达 Domain 层之前，我也没看到你提前把 DTO 转成 Domain 层 Entity，这意味着你的 Domain 层还是贫血模式。不能让Domain的上层去调用充血后的方法。比如下面的 init 方法。 ....

1、在所有的DDD书里面都会有Domain Object，唯独没有Data Object。 2、在到达Domain层之前是App层，DTO转Entity是在App层的代码里实现。 3、我这边用的是贫血模型，额外加了一个域服务来处理域内一些业务逻辑，贫血模型更适合mvc架构转过来的新人，理解成本和上手难度更底，阿里内部不少团队也都用的贫血模型。

我都告诉你了，DO，PO，VO，DTO，POJO 这套标准的是阿里的开发规范，具体看这里：https://www.cnblogs.com/EasonJim/p/7967999.html。你如果没有看过这块，你先去看一下再来回复我。 再者：阿里对DO 的定义是： DO（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。 下次回复首先回答我以下问题：

1. 你是否看过了阿里开发规范中的定义？
2. 你解释一下什么是一一对应？聚合后的Doamin Object 可以与数据库表结构一一对应吗？
3. 告诉我COLA的哪个层是或包含了 DAO层？通过DAO层向上是什么意思？
4. 你非得说DO 是 Domain Object，那就把你从哪本书看来可以这样缩写引用到你的回复中。
5. 你的 Domain 层是否依赖了 infra 层？

总结：我想说的是，沟通的前提是大家对概念都有统一的认知，这个认知来自于出处的定义。你不能指望你公司新入职的人强行让人家把 DO 理解成 Domain Object。至于团队是否选择充血确实不重要，但是要确保 Domain 能随时参与到框架中，前提是 Domain 层要保证其独立性，不依赖任何其他层

1、我就是阿里的你说看过没，阿里规范里定义的DO，你可以看我另外一个回复，已经说的很清楚了。
2、在DDD里如果要你要追求Domain Object和数据库表一一对应，那你可以抛弃使用DDD了，你先明确什么时候用DDD什么时候用MVC再讨论这个问题。
3、在COLA架构定义中Infra层包含DAO， DAO层向上是规范中定义的，在DDD中提倡依赖倒置，Domain层根本不关心是否存在DAO
4、DDD领域驱动架构设计、实现领域驱动设计、中台架构与实现：基于DDD和微服务这些书中都有明确提出来Domain Object，你自己可以找相关书看看
5、Domain不依赖Infra

PS： Cola架构也不是阿里的内部DDD架构标准，很多团队并没使用Cola，包括很多电商中台团队，例如交易、商品、店铺这些核心业务

[caizi12]

另外之前你提到阿里开发手册那里DO 是Data Object，那是因为这个手册出现之前阿里内部大部分应用都是Spring MVC架构，在这个架构下用DO没问题，后来DDD流行了，DO用来表示infra层就不适合了。 现在ddd架构里国内都不会用DO来表示infra层的模型，DO都是指的是Domain Object，Infra层统一用PO，你可以网上搜搜看。

我觉得用DO作为Data Object是没问题的，反而用PO不合适。你看Spring Data XXX都是基于Data来的，也就是把业务产生后的结果是作为数据（data）。虽然Spring没有提供一套完整的DDD框架，但是每个组件都是按照DDD思想设计的，这一点在https://spring.io/projects/spring-modulith尤其如此。只不过因为这个规范没有统一才会导致这样。我估计，随着发展，Spring也会有DDD相关的框架。

此外，千万不要把“领域对象”（也就是所谓的Domain Object）简单理解成就是一个简单对象（POJO）。“领域对象”更确切的说，是领域（业务）模型，是承载业务的，因此以后请称之为领域模型，模型是不加任何后缀的。并且是禁止用lombok设置@Data注解的，只能通过构造器或者构造方法赋值。

1、Spring Data xxx 你这个多少有点混淆，同一个简称在不同领域代表意思完全不一样，你不能因为Spring 这里是Spring Data xxx就推测出在DDD是这样就是对的，几个权威的DDD书里都没有Data Object这个概念，你们讲的DO纯粹是阿里规范定义了，Cola正好遵循了，你们认为应该是DO，这个算是阿里埋了一个坑。
2、并没有说把Domain Object 理解成一个简单的POJO， 几本书里讲的都偏向使用充血模型，如果你不用充血模型领域对象在实战的时候其实就是一个简单的POJO， 并且加不加后缀及是否使用lombok，书中并没有明确规范出来不可以用，不要觉得别人说了就觉得不能用，我觉得还是实战中不破坏大的规范分层前提下怎么快速高效怎么来

PS： Domain Object 这个是很明确的，在交流DDD问题时候简称DO也没问题，DDD设计里就没有Data Object这个概念，如果你同国外同行交流你来个Data Object对方都不知道你说的是什么，另外DO数据对象这个词非常不明确，抛开业务层面定义来说，所有Object最终不都是Data吗？

[felix9ia]

https://github.com/alibaba/COLA/tree/master/cola-samples/craftsman

@caizi12
请你把这个仓库下的这个 sample 看完再发言！我不想攻击你所谓的阿里title，还总拿 DDD 来说事儿，就后缀而言，那算是大家公认的开发规范，是为了降低沟通成本。你团队达成一致，你加成 DOOOOO 都没人拦着你。但是在更大的场合，比如 GitHub Issue 中，请遵循按照大家公认的开发规范来交流。

讲了半天你都没有讲清楚哪本“DDD开发圣经“中允许你用 DO 做 领域模型的后缀。

[caizi12]

https://github.com/alibaba/COLA/tree/master/cola-samples/craftsman

@caizi12 请你把这个仓库下的这个 sample 看完再发言！我不想攻击你所谓的阿里title

你看我之前的回复，DO我已经说了他的来由，再讨论已经没有意义了

[caizi12]

https://github.com/alibaba/COLA/tree/master/cola-samples/craftsman

@caizi12 请你把这个仓库下的这个 sample 看完再发言！我不想攻击你所谓的阿里title，还总拿 DDD 来说事儿，就后缀而言，那算是大家公认的开发规范，是为了降低沟通成本。你团队达成一致，你加成 DOOOOO 都没人拦着你。但是在更大的场合，比如 GitHub Issue 中，请遵循按照大家公认的开发规范来交流。

讲了半天你都没有讲清楚哪本“DDD开发圣经“中允许你用 DO 做 领域模型的后缀。

1、还更大的一个场合，就是cola Issue吗，哈哈，一个cloa框架还能大的过DDD权威相关的书吗，cola在阿里内部都没有推广，国外有人知道cola吗，说出来可笑啊，不要固步自封只盯着cola, 建议多走出圈子学习学习。
2、 国外几个大佬出的书都是理论讲的思想，根本不会关注你的后缀是什么，人家书中更没有说不能有后缀，我不知道你那得出的结论说不允许？ 不用后缀也没关系，为什么用后缀是考虑其它层都有后缀，为了更易区分辨别所以加了后缀。
你要非找DO是什么，给你找一个

PS 先不说我在Domain 层用不用后缀，但在Infra用DO做后缀，以及用DO解释为Data Object在DDD设计里完全是没有的，这是阿里及Cola埋的坑而已。

[wallacepang]

谁告诉你DO 是 Domain Object？从你的图上来看，在到达 Domain 层之前，我也没看到你提前把 DTO 转成 Domain 层 Entity，这意味着你的 Domain 层还是贫血模式。不能让Domain的上层去调用充血后的方法。比如下面的 init 方法。 ....

1、在所有的DDD书里面都会有Domain Object，唯独没有Data Object。 2、在到达Domain层之前是App层，DTO转Entity是在App层的代码里实现。 3、我这边用的是贫血模型，额外加了一个域服务来处理域内一些业务逻辑，贫血模型更适合mvc架构转过来的新人，理解成本和上手难度更底，阿里内部不少团队也都用的贫血模型。

怎么命名团队内部统一就好了，重要的是要有面向对象编程的思想，可以参考《实现领域驱动设计》翻译作者的实践 https://github.com/mryqr-com/mry-backend

[AHangC]

https://github.com/alibaba/COLA/tree/master/cola-samples/craftsman

@caizi12 请你把这个仓库下的这个 sample 看完再发言！我不想攻击你所谓的阿里title，还总拿 DDD 来说事儿，就后缀而言，那算是大家公认的开发规范，是为了降低沟通成本。你团队达成一致，你加成 DOOOOO 都没人拦着你。但是在更大的场合，比如 GitHub Issue 中，请遵循按照大家公认的开发规范来交流。

讲了半天你都没有讲清楚哪本“DDD开发圣经“中允许你用 DO 做 领域模型的后缀。

那位老哥说的没错的，在很多DDD的书里都拿DO表示Domain Object，阿里开始那套DO,POJO规范出来的时候，DDD在国内还没流行起来

[Jasonyou-boy]

@felix9ia @caizi12 在有关DO后缀所表示的含义的观点上，两位的理由都很有说服力。DO后缀所表示的含义可以是Domain Object的缩写,即实体(Entity),也同样可以是Data Object（数据对象）。这两种含义其实是处于不同上下文中的，Domain Object处于DDD上下文，Data Object 处于防腐层下的外部依赖上下文，即DAO层。若发生歧义，则需要请出DDD中很重要的一个工具——统一语言（Ubiquitous Language）。在团队中，项目中或者一定范围内，使用统一语言消除歧义即可。
个人更倾向于Domain Object 无后缀。
理由如下：

1. Domain Object直译为领域对象，实际上称为Entity更合适，只是Domian Object直译过来更容易理解。
2. Entity和Value Object 可以进行对比，两个有本质区别。
3. Domain Object与Data Object冲突，应该向后兼容，先来先占位，降低理解成本。
   许多名词或者缩写在不同的情景下都有不同的含义，而不同的领域本来就没有非常清晰的界限，模糊不清的上下文必然会造成的误解。在模糊上下文中不妨使用统一语言消除歧义。
   个人见解而已，很乐意与大家讨论。

[Jasonyou-boy]

就像代码风格一样，我们在同一个项目中需要统一风格。但不同项目中又会有固执己见的代码风格，本就没有对错之分。至于哪种风格会成为主流，大家会在不断实践过程中作出选择。或是大一统某种分割，又或是仅仅幸存下了少数几种风格。
物竞“天”择