本文探讨了传统架构的不足，如两层架构的局限性和多层SOA架构的问题，指出微服务架构的兴起。接着，文章介绍了DDD（领域驱动设计），强调其通过业务领域模型确定微服务边界，确保业务与代码一致性。DDD包含战略设计（业务视角，划分领域边界）和战术设计（技术视角，实现领域模型）。DDD的优势在于减少耦合、提升设计规范，适用于高复杂度业务。微服务拆分应考虑领域模型、业务需求变化、性能、组织架构、安全和技术异构等因素。然而，DDD对设计和开发人员的要求较高，适合于复杂且变化频繁的业务场景。
文章目录
软件架构模式发展到现在可以主要经历了三个阶段：UI+DataBase的两层架构、UI+Service+DataBase的多层SOA架构、分布式微服务架构。
一、传统架构的缺点
在前两种架构中，系统分析、设计和开发往往是独立、分阶段割裂进行的。
1、两层架构是面向数据库的架构，根本没有灵活性。
2、微服务盛行的今天，多层SOA架构已经完全不能满足微服务架构应用的需求，它存在这么一些问题
- 臃肿的servcie
- 三层分层后文件的随意组装方式
- 技术导向分层，导致业务分离，不能快速定位。
比如，在系统建设过程中，我们经常会看到这样的情形：A 负责提出需求，B 负责需求分析，C 负责系统设计，D 负责代码实现，这样的流程很长，经手的人也很多，很容易导致信息丢失。最后，就很容易导致需求、设计与代码实现的不一致，往往到了软件上线后，我们才发现很多功能并不是自己想要的，或者做出来的功能跟自己提出的需求偏差太大。
在这两种模式下，软件无法快速响应需求和业务的迅速变化，最终错失发展良机。此时，分布式微服务的出现就有点恰逢其时的意思了。
二、DDD领域驱动
虽说分布式微服务有这么好的优点，但也不是适合所有的系统，而且也会有许多问题。
微服务的粒度应该多大呀？微服务到底应该如何拆分和设计呢？微服务的边界应该在哪里？这些都是微服务设计要解决的问题，但是很久以来都没有一套系统的理论和方法可以指导微服务的拆分，综合来看，
最低0.47元/天 解锁文章
扫一扫
686
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
