随笔 | 开发模式演变之路| 模块划分 与 服务拆分 | 创造概念的能力,传播学
开发模式演变简述
1.jsp, asp，Servlet 前后端分离的雏形。// 附录1
html+asp: 模板+动态内容。
2. mvc时代: ssh,ssm :
明确的分离了页面和业务逻辑。通过ajax进行沟通，而不是直接调用业务逻辑代码。
此时，随着需求增加和迭代，业务逻辑会在不同模块交织。所以需要一种模块划分的方法来应对长期的需求变更，但不知道为什么，此时模块划分的并没有被广泛讨论
3.服务化：把一些模块单独部署，其他服务通过指定ip进行调用。// PS. 所以微服务只是把一个单体部署的系统，拆分成多个部分来部署而已。
此时其实就需要服务划分的方法论，但是概念还不够响亮。
4.微服务(就是带有服务注册和发现的服务化,当然还有其他的服务治理相关的东西)。
随着微服务概念的提出，模块划分的问题 被包装为 服务拆分 这个概念，被广泛的提及和讨论。
一个问题被广泛讨论，则就会产生方案。此时的明确方案就是 领域驱动设计。(六边形架构(中心(领域模型)-适配器-外部资源(数据库)) )
微服务这个概念最大的作用
就是使得很多开发人员开始了微服务的实践，在实践过程中，把原本单体架构中被忽略的模块划分问题，包装为服务拆分这个新概念并强烈的暴露出来，使得大家重视并不得不掌握模块划分的方法，进而推动开发人员设计能力的发展，推动力软件行业的进步。
微服务化对一般公司的主要意义
1.通过微服务化的实践，满足人的好奇心和探索欲，学习和实践一些分布式应用相关的技术。 实际上很多公司的微服务化对业务几乎是没有帮助的。
2.学习模块划分的方法论。我认为这点是最重要的，也是能够对业务有帮助的地方，对业务的帮助体现在: 划分良好的模块，有助于更高效的应对长期的软件需求变化。也就是提高开发效率。相信很很多人有感触，模块划分不好/服务拆分不好的系统，是严重影响开发效率的。
所以，我认为大部分公司，应该这样实践微服务化: 首先把模块划分好，然后把模块毕业成为1个服务。
但不幸，如果贵公司qps 仅仅几百，几千，却已经开始微服务化了，那么主导微服务化的人应该调整你们的目的: 本次微服务化的所有目的就是为了掌握划分模块的方法，并真的把模块划分出来。
模块划分明确后，哪怕抛弃刚刚做好的实际不必原来的单体有优势的微服务架构，转而继续对原来的单体/服务化架构，按照新划分的模块来做重构，也是不错的选择。
技术人员的两种挑战
这两者需要的知识体系也是不同的。
- 业务架构上: ddd,领域驱动设计。
- 性能架构上: 高并发，大流量。
