本文通过一个项目案例，讲述了从架构师角度如何进行微服务拆解，涉及业务、组织和技术三个维度。文章强调了高内聚低耦合的原则，并指出微服务间的交互与耦合是评估拆解合理性的关键。拆解过程中，考虑了业务模块、团队组织和通用功能的独立性，同时探讨了服务间的同步和异步通信方式。
前言：从一个故事开始
这篇文章的开始，我先给大家讲一个采用面向对象的微服务架构的项目的落地的故事，记住这几个关键字：
- 拆解
- 微服务架构
- 面向对象分析与设计
在这个故事里没有DDD，只有软件架构、软件设计与开发的探索实践、优化与思考。
第1次拆解 - 子系统
项目团队最近接了一个大项目，所以领导特别重视，领导和业务方高层一起对项目进行了整体规划，将系统分成了几子系统，并将这些子按照重要性、用途等划分成：
- 重要的，最能体现业务价值的
- 相对来说不那么重要的，但却对核心业务起到了支撑作用
- 通用的子系统，被其他多个子系统用到，又或者可作为后续团队技术资产用于其他项目的子系统
领导找到了项目负责人，告诉他重要的子系统要放在第一期做，要由咱们的技术大牛团队负责，保证质量，开个好头，也能体现出咱们团队的能力，不那么重要的可以分给咱们其他的团队来做，如果人手不够也可以交由外包团队来做，而对于哪些通用的子系统咱么可以自己做，也可以采购一些现成的解决方案。
第2次拆解 - 微服务
之后，项目经理领着产品经理和业务方专家对业务展开了交流和讨论，先是针
订阅专栏 解锁全文
扫一扫
1235
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
