战术设计是纯技术范畴的东西，最让人头痛的就是里面的名词。
贫血模式和充血模式：DDD 推荐你用充血模式写代码，也就是按照 OOP 的方式去做抽象，然后把行为挂在对象上，而不是以纯过程式 的方法去写代码。所谓的充血，就是对象本身有很多关联的行为，而不只是一个单纯的数据库的表的字段映射。DDD 声称的充血模式的优势是，大部分的行为被封装到了对象内部，这样我们在阅读流程代码的时候，是一目了然的，直接能看到 step 1，step 2，step 3。但实际上即使我们不用 OOP 来组织行为，一样可以把不同的业务 step 做好封装和复用。有些公司的服务粒度拆得特别细，比如只有 5000-10000 行代码，在 DDD 里声称的充血模式的优势没有那么明显。
值对象和实体：这个也挺离谱的，值对象就是纯粹的数值、文本类型，比如：
type person struct {
age int
name string
}
就是指对象，如果我们给这个 person 加一个 id，让它能表示 person 的唯一性了；
type person struct {
id int
age int
name string
}
那它就是实体了。
这两个概念只是给我们日常用的对象们进行了一个简单的分类，没什么大用处。
聚合根：DDD 所谓的聚合根是事务粒度的 entity，也就是说，如果我们对 db 进行存取，那么我们就需要有一个聚合根，如果在一个事务里需要操作多张表，那么就需要给多张表关联一个单独的聚合根。
聚合根本可以由一个 entity 组成，也可以由多个 entity 组成，就是你完成一个任务 db 事务的时候有多少关联的对象 ，那可能就有多少在同一个聚合根下面的 entity。
六边形架构：这个所谓的六边形架构，就是除了业务以外的所有外部变化都抽象成 adapter interface 做适配。如果你稍微理解一点点点依赖反转，那应该知道怎么样去做这种抽象。如果你一点都不了解，那我建议你去看看 go-micro 的代码。如果看不懂，建议还是尽早转行吧~
六边形架构这东西主要是名字实在起得太奇怪，在 《clean architecture》那本书里，uncle bob 也给过一张图：
《evolutionary architecture》这本书出自造词大本营 thoughtworks 的员工之手，里面有一个 plugin architecture，就是有些人特别喜欢说的插件化架构：
Repo Pattern：DDD 理论认为我们业务项目的存储这一层是可能经常变化的，所以就专门存储层的 interface 设计单独拿出来，称为 Repo Pattern，这东西实在没啥可说的，find，getlist，save，你只要有一点点 orm 经验，里面有啥接口应该自己都可以默写出来。
事实是在 2021 年，我们的存储系统基本是不太可能做切换的了，即使切换，那些新兴的社区存储系统也会支持 MySQL 协议，基础设施想要侵入代码，那简单是大逆不道啊。
领域事件：其实就是做上下游解耦的 kafka message，我们用 domain event 显得会更洋气一些。
领域服务：Domain service，顾名思义，你认为是自己部门或者组内的局部 api gateway 也是可以的。
综上，如果你是在大公司一线工作了两三年的程序员，上面这些东西应该马上就能理解，没有啥值得说的。如果是为了去架构师大会上秀一秀，你总得包装一下让自己显得没那么土吧？
战略设计
====
Domain：领域，你们公司是干啥的，你都不知道吗？
Core Domain：你们公司的卖货的，那卖货就是你们与其它竞争对手的关键竞争环节。这就是核心域，就是核心业务，为啥聪明人都往核心业务挤？核心业务的汤也比边缘业务的饭好啊。
SubDomain：你们公司的卖货的，但是用户没法付钱，那也没法干，支付就是子领域。
Supporting Domain：你们公司是卖货的，但是客户想看一些指标，你总得有系统能支持吧？可能就是些写写 SQL 的系统。支持域。
Generic Domain：你管你们公司干什么呢？员工的在职离职，工资发放总得有系统能支持吧，这些就是通用域。
除了第一个 Domain ，其余四个 domain 重要性逐级递减，递减的意思是，如果公司要裁员，那是从下面往上面裁。
前面我说有些程序员觉得 DDD 战略设计没用，你连自己所在的组，从事的工作职责对于公司来说重不重要都不清楚，那被裁的时候也别哭哦。
统一语言：这个就更好理解了，比如跳水这个词，你说跳水的时候指的是这个：
而你同事说跳水的时候指的是这个：
这里你们聊的是工作，那说明你们一定不是在同一个上下文里工作，可能你们俩一个在体育赛事部门，另一个可能是在金融部门， DDD 认为可以用统一语言来进行领域划分工作。划分后在同一个上下文内，同一个名词大家说出来意思一致。这就是 Bounded Context， ain。
既然拆分了，如果我们还在同一个 domain 内，那完成业务流程是需要协作的，这个不同 Context 的协作方式就叫 Context Maps 或者 Integration Type。
名词很恶心，但具体的方法就两种，两个微服务要么通过 RPC 通信，要么通过 MQ 通信。
如果通过 RPC 通信，那 callee 一般是 caller 的爹，很多时候 callee 挂了是要影响 caller 的(当然也有熔断之类的方法避免一起死)。
通过通过 MQ 通信，那上游一般是下游的爹，因为上游一个重构，下游们可能就都炸了，最终一致都是屁话，多少公司的最终一致都是靠人肉修的。
这种爹和儿子的关系就是 Conformist 。如果爹能多考虑一下儿子的需求，那就是 Customer-Supplier 关系，毕竟顾客名义上还是上帝。如果跨系统有一些需要共享的定义，比如公司里的业务分类，可能大家都要从某个系统的 PHP 文件里解析出来在自己的系统里去用，那这时候可能得去使用别人的代码，这种叫 Shared-Kernel，Kernel 一改，大家一起死。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
最后
文章中涉及到的知识点我都已经整理成了资料，录制了视频供大家下载学习，诚意满满，希望可以帮助在这个行业发展的朋友，在论坛博客等地方少花些时间找资料，把有限的时间，真正花在学习上，所以我把这些资料，分享出来。相信对于已经工作和遇到技术瓶颈的朋友们，在这份资料中一定都有你需要的内容。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
的时间，真正花在学习上，所以我把这些资料，分享出来。相信对于已经工作和遇到技术瓶颈的朋友们，在这份资料中一定都有你需要的内容。**
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-TJKkURrX-1712887717389)]
265
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
