基于领域中心的进程内架构落地讲解&完整项目代码示例

# 引言

好久没有写自己的文章了，特别在CSDN上写的特别少，最近参与了公司的一个读书分享（Get Your Hands Dirty on Clean Architecture）发现了很多和本书作者共鸣的地方，也借着这个机会和大家总结下自己理解，如果没读过这本书的，也可以快速通过这篇文章帮你获取核心知识点。

这个文章主题是进程内架构落地实践，为什么要说落地，是因为后面会给大家看代码，毕竟理论相对抽象，很多文章你就算看完了实际上你还是不知道怎么做，所以阅读这个之前你可以放心最后会有完整的代码示例，你可以下来仔细去了解。

# 为什么需要了解进程内的架构设计

这个是一位技术人员，目前了他有一些空闲时间，他在review他们项目上的技术问题，看看是否能够解决之前遗留的技术债，要保证可维护性，减少开发成本，作为技术人员，肯定要追求卓越，美观的结构也是必不可少的，balabala...脑袋里面各种想法开始碰撞。
如果顺利的话，我们就可以开始优化之路了，但是现实往往很残酷，这个时候你会突然听到一个声音：等等！

他叫住你干嘛呢，我这边举例了三个比较常见的情景：

• 第一个就是你的合作伙伴找到了PM, PM突然找你，说我们之前提供的那个接口需要修改下，以适配他们的新的规范来，这个时候你很困惑，为啥呢，应为之前他们不是这么说的，并且规范之前也是对齐了的，现在又要改，不我不该，PM你去battle，好的情况是battle赢了，但是往往大部分的结果可能是：项目经理的实力不足以赢得与外部合作伙伴的战斗，或者外部合作伙伴发现 API 规范中的漏洞，并证明其正确性，还有最常见的一个理由外部合作伙伴还需要x个月来修复这个API，那最后都会还是需要我们自己去解决
• 第二个场景是PO或者项目经理，突然给大家说，这边来了一些新功能，并且要在这次的deadline一起上，你心里一咯噔，赶紧看一下时间，你发现还有3天就是deadine了，心里只能无数头caonima跑过去。
• 第三个场景是，你的客户突然找到你，他说有一个什么资料，可能是会议相关的，可能是报告，让你帮忙整理下然后发给他们，然而这个时候你已经很忙了，但是也不得不回复一个：好，内心默默流泪

那在这些场景的干扰下，你对于最开始做技术优化的想法很可能就会变成下面图片这个样子，有些小伙伴可能内心还是会过不去，甚至安慰自己，不是我不愿意追求技术卓越，而是没有条件

那怎么解决这个问题呢？首先我澄清一下，我们今天聊的解决方案是站在架构的视角，来帮助项目应对各种这样的外部变化，而减少对代码的腐蚀，避免总是采取捷径，捷径是什么意思呢，就是前面那个人的感叹，怎么简单怎么来，这种思路下往往是造成代码，架构快速腐化的元凶。那有没有一种架构能够像积木一样，具备很强的灵活性，适应性强，我们可以控制我们自己的立场，避免总是采取捷径的无赖呢？

---答案就是接下来会讲的这本书中的核心知识。

# 一些基本概念

在继续具体内容之前先对一些词做一个解释，防止小伙伴们产生歧义或者不太了解。

# 什么叫进程内架构

这个顾名思义就是在单个进程内运行的服务的架构设计，也就是实际运行起来作为最小个体的服务代码库的内部代码结构，它不是那种跨进程的多服务类别的架构设计，如果还是无法理解，我提一个东西你一定知道那就是三层架构（web,service,repository），以前我们写代码的小伙伴们应该都接触过，那你们所了解的三层架构就是这里聊到的进程内架构的一个实例，到后面还有什么很多其他模式，例如前端的MVVM，DDD的六边形架构等。

# 什么是领域中心的架构

说道领域模型，最近业内特别频繁的一个词就是DDD，各个大厂也都在落地自己的DDD，但是由于DDD的思想本身是抽象的，到后面才有了IDDD，它帮助指导了落地的具体步骤，但是实际上如果你有过落地DDD的经验，你就会发现不同的架构师或者技术负责人对于DDD具体落地的结构是有一套自己的认知的（大的方向可能一样，但是小的结构区别蛮大），这种问题就导致，不同项目上可能进程内架构风格五花八门，尽管都是DDD（这里有个前提是公司内部没有制定强制的统一的架构标准）。

那谈到了DDD往往就会聊到，整洁架构（clean