我把《软件方法》第1章"1.1.2.3 微服务的遮羞布"交给Nano Banana Pro，让它生成漫画。AI生成的8格漫画如下：
原文如下：
1.1.2.3 微服务的遮羞布
最近几年鼓吹的新词"微服务"造成一定的误导。有的人误以为"微服务"就是"需求设计一一对应"。
假设考虑到开发团队的结构，把系统分成多个"微服务"，分由各个小团队应用各自的技术栈独立完成。例如图1-1中的男士，可能会被分割为"996微服务"、"交作业微服务"、"扛煤气罐微服务"。
且不说这样划分是否合理，即使这样划分了，"微服务"内部也要通过自己的各个部件（可能是残缺的）协作完成，例如"交作业微服务"要完成"交作业"用例，也需要眼睛、耳朵、手、脚、心脏、**等（可能是残缺的）协作完成，并非映射一个"交作业模块"然后就搞定。更何况，有的用例需要若干个"微服务"协作才能完成。
另外，"微服务"是妥协的不良结构。如果这样的划分风格所得到的软件结构真的是良好的结构，我们几十年前就可以这样做，难道之前的复杂系统没有分解吗？不需要分解吗？如果这真的是好的结构，放在什么时候都是大杀器，根本不用等到现在，拿"微服务"（这也是一个造词）之类的作为理由。即使是一个人完成的项目，也不妨引入一个假设"由各个小团队应用各自的技术栈独立完成"来改善软件的结构嘛。
"微服务"所要解决的问题，在某些系统中确实是存在的，但我在这里要提醒读者，提防把"微服务"（或类似手段）当成遮羞布。
一个人没有能力解决主要问题时，他可能会采取一些措施来掩盖自己能力不足的事实，其中之一就是引入次要问题。
这也是人之常情了。例如，我们在工作中碰到头痛的问题，有时会逃避着不去碰它，而去做一些整理文件，回复邮件等琐碎的事情来获得成就感。
我用盖大楼作类比：
两座大楼耸立在那里，要判断地震来了哪座大楼不容易塌，要考虑的是大楼的结构、所用的材料、所在位置的地质环境等，和这座楼是哪家公司建造的，要了多少钱，建造大楼的公司内部是怎样的组织结构，一共有几支工程队，当时怎么分工的，甚至大楼是猫建造的、狗建造的、外星人建造的，已经没有直接关系------因为大楼已经在那里了。
但要研究这些让大楼不容易塌的直接影响因素，涉及到艰深的工程力学、流体力学、岩土力学等知识。架构师李三没把这些知识学扎实，正在那里犯愁呢。
这时，伪创新专家张四出现了。张四说，时代变了，现在盖楼要讲"新建筑学"，要考虑到人际关系，要搞好团结。
于是，李三想着反正"老的"工程力学那些我也搞不懂，还是搞"人"轻松一些。这样吧，有几个包工队跟自己混，就分几个包，大家开干就是。
转换思想后，李三每天累并快乐着，灯红酒绿，推杯换盏。
而且，运气好的时候，盖出来大楼确实也能住人。
如果李三说，公司又不是我的，想那么多干什么，这可以理解；
如果李三说，这么干盖楼快，反正老板要的就是在某某大日子到来之前有个样子货交差，这也可以理解；
如果李三说，这么干有利于建筑团队的安定团结（虽然坑顾客），这也可以理解；
就怕张四以李三为案例，搞出一个"新工程力学"，说这样盖出来的大楼更抗震，甚至到清华大学建筑学院开课"划时代革命性的工程力学"，取代原有的"工程力学"------这就是无耻了！