banq

由于google翻译从中国撤退，而且chrome浏览器将google翻译作为独立线程，不走chrome的代理，而gstatic.com是楼主设置中用来判断走国内还是国外关键，需要将这个测试网址标记为DIRECT： # 添加规则 prepend-rules: # 规则由上往下遍历，如上面规则已经命中，则不再往下处理 - DOMAIN,gstatic.com,DIRECT - RULE-SET,applications,DIRECT - DOMAIN,clash.razord.top,DIRECT - DOMAIN,yacd.haishan.me,DIRECT - RULE-SET,private,DIRECT - RULE-SET,reject,🛑 广告拦截 - RULE-SET,icloud,DIRECT # - RULE-SET,apple,DIRECT # 这三个为国内可直连地址，如果希望走代理改为PROXY - RULE-SET,google,PROXY # 其中google改为走PROXY，这样开启tun模式以后，谷歌chrome浏览器中的谷歌翻译能通过代理完成翻译功能。

非常抱歉，精力有限，可先阅读文档：https://www.jdon.com/ddd/jivejdon/1.html 更详细的领域模型设计解说见出版书籍，DDD软件主要看领域模型是如何设计的。

Pls. replace en.jdon.com with cdn.jdon.com in pom.xml

直接失效这个功能，在web.xml中去除下面： ` spamFilterRefer *.shtml spamFilterRefer *.jsp ` ` spamFilterTooFreq *.shtml `

服务直接暴露接口作为API，是一种简单做法，在复杂案例情况下，两者最好分离。 基础层只有仓储Repostiory层，复杂项目中基础层包括消息中间件。由于是简单案例，直接使用仓储层默认作为基础层。 这个案例主要展示订单聚合的实现，不是完整DDD架构实现，完整DDD+六边形架构可参考jivejdon

OrderStatus是值对象，但是表现为数据层的实体，这是JPA技术限制。

这句话意思是：数据库是需要主键的，主键是标识，而值对象则是无标识的，那么值对象保存到数据库中是不是一定不能有主键呢，不一定，在DDD中是值对象，但是在数据库中可能就是一个实体数据表，由实体数据表转为的对象称为数据层的实体对象，这个实体对象是DTO或POJO，是贫血对象，与DDD中实体不是一个概念

你说得有一定道理。主要看业务逻辑放在哪里，贫血模型中是不能放入业务逻辑的，那么业务逻辑只能放到服务中，当然还有其他情况，不确定业务逻辑是否放入服务中，或者不自觉无意识放入服务中，例如检查钱够不够，这个动作是否有主语？谁检查钱够不够？谁的业务规则中有对钱的余额限制，有余额限制才会去检查钱够不够，我们是否忽略了这个“谁”的主语提炼？实际上是业务规则所在的地方，也就是业务逻辑所在的地方。

是啊，业务逻辑划到服务中，实体就变成了贫血模型，失血，失去业务逻辑这个血液了，而且服务本身是一种桥梁作用，如同饭店的服务员，业务逻辑核心不应该在服务员那里，而是应该在老板或厨师那里，服务员只是将业务逻辑这盆菜送到客户桌子上，老板或厨师等业务实体决定了业务逻辑，是整个饭店的核心。 将业务逻辑放入服务之中是很多人对服务这个定义没有明确，服务是客户端和业务实体之间的桥梁，不是业务核心所在，如果将业务逻辑放入服务中，服务就臃肿，且难以修改，这是一种过程化编程，粒度太粗，铁板一块了，而且难以复用业务领域逻辑，因为服务有时针对不同客户端会有不同功能，但是背后的业务逻辑是一致的，例如服务A调用业务实体的检查余额是否够的方法，如果返回足够，那么服务A就会去保存数据到数据库；而服务B也是业务实体的检查余额是否够的方法，如果返回足够，那么服务B就会发送消息到基础设施层通知其他模块的服务，你看服务A和服务B有细微差别，背后共享的是可重用的同一个业务逻辑规则：检查余额是否足够。 现在大部分系统都是无意识地将业务逻辑放入服务中，以服务为主，业务实体为辅助，业务实体实际就是贫血模型了。DDD主张将业务逻辑放入业务实体中，变成充血模型。这就是DDD与众不同之处。 当然，有一些功能服务放入相应的业务实体中，那么可以放入服务中，这种服务也称为领域服务，但是领域服务相比充血模型的业务实体只是一个配角位置，如果将业务逻辑核心都放入领域服务，并且声称无法放入相应业务实体，那时自己没有认真进行聚合设计而已，是对业务的一知半解，这是一种技术债务，未来会被偿还的，不是不报，时候未到。

当然，上面服务A和服务B如果想重用检查余额这业务逻辑，可以不把检查余额设计到业务实体中，而是抽象到另外一个服务C中，这样服务A和服务B都调用服务C，以此类推，很多业务逻辑没有散落在各个服务中，如服务C是检查余额，服务D是扣除余额等等，其实无论是检查余额还是扣除余额，都是可以归纳到一个称为"账户"的业务实体中，散落在服务C和服务D中这两个动作其实都属于账户这个业务实体的行为动作。 当然，也可以设计一个AccountService和Account，Account是只有setter/getter的贫血对象，AccountService是将原属于Account中的检查余额还是扣除余额动作放入其中，这会造成Account中的余额这个状态属性没有被守卫，没有被看护，一个新的程序员在AccountService中新增任意其他方法对余额进行修改，当我们查看Account代码时，只有setter/getter方法，搞不清楚余额属性状态是在哪里被修改的，被什么业务逻辑修改的，这实际就是数据结构和对象的区别，这种Account是贫血模型，是一种数据结构，没有业务行为，不是真正的对象。 著名大师鲍勃大叔文章：https://www.jdon.com/52533