文档 本工程采用DDD的架构风格，经过组内DDD实践的沉淀形成的工程规范 DDD实践的参考文档详见： DDD实践参考文档 工程结构： --client/ |-- src |----|-- main |----|----|-- java |----|----|----|-- com.sankuai.crayfish.xxxx |----|----|----|----|-- service -- thrift服务 |----|----|----|----|-- model -- thrift对象定义 --server/ |-- deploy |-- src |----|-- main |----|----|-- java |----|----|----|-- com.sankuai.crayfish.xxxx |----|----|----|-- application -- 应用层 |----|----|----|----|-- service -- 应用服务 |----|----|----|----|-- factory -- 对象转换工程（非必须） |----|----|----|....
背景 X项目组后端工程都是根据DDD的规范搭建的工程，整体结构上是统一的，但是在实现细节上，每个人习惯不同，代码风格有很大差异，导致工程之间的风格迥异，维护成本变高，因此需要梳理一套组内通用的项目工程规范，通过规范让编码风格统一 目标 建立一套组内通用的工程规范，组内成员达成一致，严格按照规范执行，以达到提供代码可读性、工程可维护性的目的。同时提高协作沟通效率。 调研 领域驱动设计调研 结论：需要根据自己的业务需求，建立适合业务场景的架构模式。没有统一的答案，每个团队在DDD实践上都有自己的理解，并没有统一的标准 1.规范组成 主要有两大部分组成： 开发规范 运维规范 名词解释 规范约束词： 强制： 必须遵守 推荐： 建议的做法，通常情况下是最合理的 参考： 提供一种综合考虑较优的方案 2.DDD工程实践概述 领域驱动-补充资料-分层架构的背景 分为四层： （1）用户界面层（或表示层） （2）应用层 （3）领域层 （4）基础设施层 各层的关联方式： 各层之间是松散连接的 层与层之间的依赖关系只能是单向的 上层可以直接使用或操作下层元素，方法是通过调用下层元素的公共接口，保持对下层元素的....
分层领域模型命名约定 DDD分层领域模型规约： DTO（Data Transfer Object ）：Thrift/pigeon 接口定义对象命名方式，命名方式XxxDTO DO（Data Object）：持久层对象命名方式。命名方式XxxDO Entity（实体）：代表一个领域实体。命名方式XxxEntity ValueObject（值对象）：代表一个领域值对象。命名方式XxxValue 应用层 1.【强制】禁止在应用层写任何领域逻辑，仅负责协调领域模型对象，通过它们的领域能力来组合完成一个完整的应用目标 2.【强制】与横切关注点相关的内容应该放在应用层 3.【强制】thrift接口参数校验属于横切关注点，应该放在应用服务来做 实体 1.【强制】实体对象的命名以Entity结尾。比如UserEntity、CompanyEntity 2.【推荐】Entity<->DO转换建议使用Mapstruct（参考本文【mapstruct对象转换示例】），除非有足够的理由不使用。 3.【推荐】实体尽量使用充血模型。属于实体的行为必须放在实体中，不能放在聚合根中，否则会造成实体贫血 4.....
1.分层架构的背景 为什么要分层 在软件中，虽然专门用于解决领域问题的那部分通常只占整个软件系统的很小一部分，但其却出乎意料的重要。我们需要将领域对象与系统中的其他功能分离，这样就能避免将领域概念和其他只与软件技术相关的概念搞混了，也不会再纷繁芜杂的系统中完全迷失了领域。 分离领域的复杂技术早已出现，而且都是我们耳熟能详的 软件系统有各种各样的划分方式，但是根据软件行业的经验和惯例，普遍采用LAYERED ARCHITECTURE(分层架构)，特别是有几个层基本上已成了标准层。分层这种隐喻被广泛采用， 大多数开发人员都对其有着直观的认识。许多文献对LAYERED ARCHITECTURE也进行了充分的讨论，有些是以模式的形式给出的。LAYERED ARCHITECTURE的基本原则是层中的任何元素都仅依赖于本层的其他元素或其下层的元素，向上的通信必须通过间接的方式进行。 四层架构的依据 分层的价值在于每一层都只代表程序中的某一特定方面。这种限制使每个方面的设计都更具 内聚性，更容易解释。当然，要分离出内聚设计中最重要的方面，选择恰当的分层方式是至关重要的。在这里，经验和惯例又一次为我们....