罗小爬的技术宝书

将多个组件链接成一个独立可执行文件（war、jar、ext），并以动态加载的插件形式来部署（组件化的插件式架构）。组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最新小实体（jar、dll）。设计良好的组件都应该永远保持可被独立部署的特性，同时也意味着这些组件应该可以被单独开发。在这些情况下，“软件模块”指的就是一组紧密相关的函数和数据结构。大部分情况下，其最简单的定义就是指一个源代码文件，既然改变不可避免，那就将变化隔离在单独的组件，让变去依赖不变（不稳定依赖稳定），

可以参照UML中活动图，在活动图中提出了泳道的概念，即在原业务流程图的X轴方向上添加了泳道的划分，不同的泳道即表示参与流程的不同角色。复杂业务需求通常伴随着复杂的业务流程（一个或多个），呈现业务流程最直接的方式就是运用业务流程图，业务流程图为动态的业务需求提供了简单清晰的可视化方案，可以帮助受众快速了解业务本身的运作方式，明确业务规则。）分割为执行业务活动的不同区域，分割出来的各个区域代表了不同角色的活动类型，也体现了不同的观察视图，在保证业务流程全貌的基础上清晰地体现了参与角色、活动类型等的不同特征。

本文主要介绍了聚合的识别原则以及聚合间的协作方式等。

本篇作为识别聚合的前哨，介绍了实体、值对象的识别及定义等。

书接上回的JPA仓库实现，在定义完商品聚合内相关的根实体Goods、值对象等，接下来我们还需要为根实体Goods定义相应的仓库Repository接口。

本篇文章继续以前一篇中的商品聚合为例，但是领域模型和仓库Repository实现均借助于Spring Data JPA。

书接上回，之前通过一个关于拆解、微服务、面向对象的故事，向大家介绍了如何从微服务、面向对象一步步演进到DDD的，整个演进过程如下图：其中在领域层，我们定义了富血模型的领域模型，包括聚合、聚合根、实体、值对象等。聚合在代码层面中的表现形式即是一个包Package，起到了边界的作用，聚合内的对象间高内聚，而聚合间低耦合。聚合中放着实体、值对象、仓库等，实体相较于值对象的一个典型区别就是实体存在唯一标识，并且可通过该唯一标识查询到该实体并对其进行相关操作，值对象不存在唯一标识且通常作为实体。

通过这个故事，我想要传达的就是不要为了DDD而DDD，尤其对于初学者不要上来就去学习DDD中的各种迷惑性的概念和术语，本文通过拆解、微服务、面向对象的视角向读者介绍了一个系统是如何一步步走向DDD的，只有建立在理解的基础上，充分理解了各种模式的使用场景及动机，才能真正发挥各种模式的优势，放下DDD也许你才能真正体会到DDD。我们做的设计最终都是要指导落地的，搞那么多迷惑性的概念和拆解除了能让PPT上多一些谈资，似乎给指导落地并不能带来任何实质性的帮助。

用户类中的属性，如ID、用户名等，我们可以直接使用编程语言的原生类型如Long、String进行建模，但其本质也是类的定义，同理我们也可以通过自定义类的形式来定义属性，例如用户身份证号属性，原本使用String类型表示，但随着后续业务的梳理，需要通过身份证号解析出用户所在的省市区、出生日期等，出于单一职责的考虑，我们可以创建一个身份证号类，该类持有身份证号属性，并提供获取省、市、区编码、获取出生日期等方法。

拆解微服务架构面向对象分析与设计在这个故事里没有DDD，只有软件架构、软件设计与开发的探索实践、优化与思考。

CURD Boy的三宗罪：Mybatis、事务脚本、贫血模型，你占了哪几样？

本文结合笔者开源项目d3s介绍了如何通过maven插件集成smart-doc，并同步接口文档到Torna。

目录一、背景二、动机三、实现思路3.1 权限类型、操作类型3.2 统一用户及数据权限集合模型3.3 定义数据权限拦截注解3.4 提取配置属性3.5 数据权限拦截器实现四、集成方式五、关于D3S一、背景最近一直在做RBAC相关的架构设计与实现，传统的RBAC的权限控制只是控制到REST接口（url）、具体方法（权限码）等，而通常实际业务场景还需要对数据权限进行控制，例如：用户仅允许查询自己的用户信息，不允许查询其他人的用户信息用户仅被允许查询 同部门 或 同部门及子部门 的用户信息用户仅允许查询指

本文主要介绍了DDD的相关概念，帮助读者对DDD有一个入门的印象，后续笔者会陆续发布更多关于DDD落地的文章。

最近在学习DDD应用架构设计时，接触到了不同的应用架构设计概念，如六边形架构、洋葱架构、整洁架构、清晰架构...，起初是一头雾水，在不断学习过程中也算对此有了些理解，故在本文中对这些架构进行了简单的介绍和总结。............

最近在团队内部搞了一次DDD分享，效果还算不错，在此特将本次分享所用的PPT分享给大家，大家共同学习，也随时欢迎大家提问和讨论。