我这里的项目名中包含service的项目，其实相当于用户接口层和应用层的合体
其中：application 属于应用层，负责编排各个领域的调用逻辑，但是该层本身没有业务逻辑
application 里面的 service, 其实就是领域服务，负责编排业务代码，操作不同的领域
     比如 订单领域需要扣除商品领域的库存： Result result = productClient.deductProducts(productAndNumber);
     我这里对领域实体（聚合根）的调用，必须由领域服务来完成
  application下面的  assembler,cqe,dto,其实可以考虑放到 interfaces.fadace里，由用户接口层转换成应用层（领域服务层）所需要的 参数
interfaces.fadace 相当于用户接口层；负责对用户参数的封装，和响应结果的封装。里面就是controller


在订单领域中，application 通过 feign 获取 product 领域对象 是不对的，应该调用 product 里的 applicaiton （领域服务）
但是呢，一个领域服务不能调用另一个领域服务；application 应该是应用层才对。。。领域服务写在 domain 里；
那应用层是否可以依赖多个领域服务的包呢？这是个问题；好像是可以的
我这里的缺点是将领域和应用没有做区分。。。
比如订单领域；；和订单应用。。。
有文章说领域服务写在领域层中，就是domain中，那这样的话，我这里就没必要区分那么多的应用层了，一个就够了。。。


====https://blog.csdn.net/leesinbad/article/details/127797049
领域服务是在领域层
interface -> application | domain | infrastructure
application -> domain | infrastructure
domain -> infrastructure
上面的也不一定好：https://booksea.blog.csdn.net/article/details/12724895

interface： 用户界面层，或者叫表现层，负责显示数据或者解释用户命令
application：定义软件要完成的任务，并且协调指挥领域对象进行不同的操作；该层不包含业务领域知识
domain：领域层，即包含了该领域（问题域）所有复杂的业务知识抽象和规则定义。该层主要精力要放在领域对象分析上，可以从实体，值对象，聚合（聚合根），领域服务，领域事件，仓储，工厂等方面入手
infrastructure：基础设施层，主要有2方面内容，一是为领域模型提供持久化机制，当软件需要持久化能力时候才需要进行规划；一是对其他层提供通用的技术支持能力，如消息通信，通用工具，配置等的实现；

应用服务用来编排领域服务；
领域服务用来编排聚合；
聚合内实体以充血模型实现个体的业务能力
聚合根也称为根实体；在聚合与聚合之间，聚合根还是对外的接口人，以聚合根ID关联的方式接收外部任务和请求；也就是说聚合之间通过聚合根ID关联引用；

上下层级依赖的解释：https://booksea.blog.csdn.net/article/details/127248954
架构根据耦合的紧密程度又可以分为两种：严格分层架构和松散分层架构。优化后的DDD 分层架构模型就属于严格分层架构，任何层只能对位于其直接下方的层产生依赖。而传统的 DDD 分层架构则属于松散分层架构，它允许某层与其任意下方的层发生依赖。那我们怎么选呢？综合我的经验，为了服务的可管理，我建议你采用严格分层架构。



https://booksea.blog.csdn.net/article/details/127248954 这篇文章说 值对象冗余其他领域的数据，其他领域的数据变更不影响值对象
https://booksea.blog.csdn.net/article/details/127248954 todo 各层的功能介绍

问题：领域层是否可以依赖仓储层，如果依赖的话，需要spring去注入，但是领域层的实体，都不是单例的，有人建议 ApplicationContextUtils 来获取仓储层的对象，甚至在领域层封装个工厂，专门用于查询指定的实体；
domain是否可以引用 仓储层呢 ？


https://blog.csdn.net/wanghaiping1993/article/details/125433802
=====
1113开始干活
interface：用户界面层，里面包含参数及数据转换；只有一个模块；；；；
application：应用层，里面负责编排各种领域服务，依赖 各种领域层；还有公共服务层；仓储层；只有一个模块
domain: 领域层，里面有聚合，聚合根，实体，值对象，领域服务；多个领域的话就有多个模块
仓储层：负责是持久化数据，领域层可以定义数据接口，然后由仓储层进行实现；仓储层依赖领域层；但是应用层依赖仓储层时，就顺便也依赖了领域层，感觉不符合实际，或者领域层单独出一套API，仓储层实现。。
        仓储层不依赖领域层，仓储层有自己的对象转换方法或类，这样的话，应用层需要调用下仓储层持久化方法；孰优孰劣 。。。。
        有文章说应用层发布调用仓储层，存储成功后发布领域事件
公共服务层：负责生成全局唯一ID，分布式锁，数据字典的查询；redis，mq的操作

明天开搞
两个问题：1：领域层是否定义接口，让 仓储层进行依赖，如果让，那么仓储层依赖领域层，应用层在引入仓储层时就会同时引入领域层。
如果不让，那仓储层存储的对象，比如方法入参出参，这些参数定义在那里？从领域对象到 pojo对象的转换方法，写在那里？，仓储层必须依赖领域层；
可写一套领域层的api,让仓储层来依赖。。。这样的话，领域层会多出一份api。
领域层的api,不能将多个领域层都放一块，这样a领域依赖api,同时也会将b的领域对象引入，这是不对的
新模块名没有 cashcow
interface 多了一个
application 多了一个
domain 不多不少
#domain-api,多了很多 （repository-api）放到 domain 中，repository 依赖domain,调用也是在domian中调用，ApplicationContextUtils 来获取仓储层对象
service 少了很多
repository 不多不少

有 application 通过 dubbo 调用 repository
有 interface 通过 feign 调用 application

有 application 通过 dubbo 调用 domain 的领域服务
有 application 通过 dubbo 调用 repository 做存储
repository 依赖 domain 的 api,
application 调用 application 的领域服务，是远程调用，还是 依赖代码的方式调用呢？
依赖代码，可以少写很多参数，但是会使很多领域服务，对象 报漏在应用层
如果依赖api的话，应用层只需要依赖领域层的api就行，仓储层也依赖领域层的api，这样可以使领域层保存干净

interface -> application (在interface 层，做输入输出的参数转换)


cqrs:查询可通过view直接查仓储层，获取聚合根，然后转换数据；不在经过应用层

# 就按照下面的办
interface ->(ai-aa,写在 ai)-> application -> (代码依赖) -> domain ->(ad-ar,写在ar,在ar里将数据转换为自己需要的，要有领域对象的创建方法) -> repository
interface 1；application：1；domain 多，被应用层代码依赖，domain-api(多) ， repository 依赖domain-api,多  ### 就这么干
interface -> application (参数转换写在interface 中)；貌似是谁作为调用方，谁去写参数转换；通过feign调用；但是接口的入参，都是写在被调用方的
application -> domain ，通过feign调用，domain写controller ，也出一套feign的api；
    如果应用层代码依赖领域层，那么会依赖过多的领域服务；好像也没什么不好的，就这么干
application -> repository (不在应用层调用仓储层)
domain -> repository repository 不在应用层调用；domain 本来应该依赖 仓储，但是最好让仓储依赖领域。这样领域定义api,有仓储进行实现，然后在领域层调用仓储层
需要多写一个 domain-api，domain 给application的api，是远程服务的api;给仓储层的api,只是单纯的接口jar包;

现在纠结 application 该怎么调用领域层；直接代码引入和 接口调用，该怎么取舍
另外，领域层报漏给仓储层的接口，不应该报漏给应用层？（领域层不能直接引入仓储层，做直接调用的）
报漏接口的话，领域层应该报漏领域服务给应用层
直接调用的话，应用层会不会太臃肿。。。可以看到很多领域代码的实现了。

接口引入的话，需要写参数转换，应用层参数转换成领域层参数，通过feign调用；

interface 1；application：1；domain 多，被应用层代码依赖，domain-api(多) ， repository 依赖domain,多  ### 就这么干

interface 通过 feign 调用 application ,参数转换写在 interface 里
application 代码引入 domain，只能调用领域服务或者聚合根，领域服务不能调用其他的领域服务（领域服务是单独领域下涉及多个实体的）
user:user 领域，里面有领域服务 （通过applicationContext 获取仓储对象）
user-repo: user的仓储层,依赖 user-repo-api，在领域层通过 applicationContext 获取仓储对象来操作，或者在应用层直接注入来操作
user-repo-api: user领域 给 user的仓储层 提供的接口,api本来就是从领域层分出去的
    api 依赖user，还是 user 依赖api呢？

    1：api 依赖user的话，user想调用api怎么办？不能调用，必须在应用层调用。其实这样也好,有应用层控制什么时候持久化，
    但是 应用层依赖领域层，不依赖api层，这样是没办法调用仓储层的；即使 通过 applicationContext ，也无法获取接口

    2：user 依赖api的话，api里面的实体类，聚合根得在 api定义，这显然是不合理的

    3：api层的代码，写到 领域层，删除api模块，这样仓储层依赖 领域层，但是仓储层不能被其他层依赖。。。；同时，本来应该写在api层的代码，只能在领域层调用。
    对象转换的操作，应该写到 仓储层，这样应用层想存储对象，必须调用领域层的方法，由领域层调用 仓储层

    结论：1：不行，领域层无法调用持久化接口，应用层只依赖领域层，也是无法调用持久化接口的
        2：不合理
        3： 可以，就这么干，删除 api模块;但是 领域层的所有代码通过jar包的方式，都报漏到应用层了;
        （3；在思考下
        3也不行，陷入到死胡同了，首先领域层不依赖任何，但是领域层要调用 仓储层来存东西。。。。，
        ProductRepoFacade 引用的配置写在 application？对，就写在application里

工具类通过 feign  来调用，interface 通过 feign 调用 application
application 代码引入 domain,
domain 通过 applicationContext 来获取仓储服务对象，甚至 领域层依赖仓储api，就不用 applicationContext 来获取对象了
仓储层通过 dubbo 来发布服务
应用层或者领域层，怎么调用 仓储呢？
仓储依赖领域，如果应用依赖仓储的话，应用就相当于把仓储和领域都拿过来了,既然仓储层都引用过来了，那直接代码调用，不必dubbo了 如果在领域层写dubbo消费者代码的话，领域层就会多很多配置。。。