关于 UML、4+1 视图、系统架构的思考



系统架构是承接需求和代码的桥梁，用来填补需求和代码之间的鸿沟，这也是架构师的意义所在，能够基于客观世界，进行抽象，建立与客观世界映射的模型，具体建模时，会使用到建模工具（UML）和工具组合，建模方法论（4+1视图，C4），最佳实践（智慧老师提供的架构文档）。



对于小的系统没有架构，基于需求直接编码是没有问题的，但对于复杂的系统，如果没有架构，那么没有骨架，系统融成一团，系统成了一个黑盒，系统的开发、运维、沟通成本一定非常高，即使系统能勉强上线，那么后期系统的可扩展性、可维护性基本上是灾难。



架构一定是基于场景的，架构的演变也是基于场景的，不依赖场景的架构是耍流氓，简单的理解就是需求进架构出。



通过本次课程学习，澄清了我之前的一些观念，同时对UML、4+1视图、建模等理论也有新的认识。



1.组件图虽然书本上看上去特别丑，但是很有用，之前一直认为组件图在系统架构中没有用处，现在回想起来，组件图用处太大了，只是没有认出是组件图而已。组件图对应功能逻辑划分和物理部署，是架构师把控架构、团队分工协作、接口定义等重要工具。组件图的组件与微服务、DDD中的支撑域、核心域、通用域，我觉得是相通的，面向的问题域是相同的，只不过是在不同的研究体系中，专业术语不同。



2.架构基于场景的，这个从4+1视图中能看出来，不同侧面的架构都是在围绕场景，这个就是中心，是架构中的中心。试想一下，一个脱离实际场景的架构，如何被群众接受呢。



3.UML视图，UML(7种核心视图）与4+1视图，软件三大阶段有对应关系，UML只是工具，描述了使用场景，但是如何使用，如何系统性使用，如何使用是最佳实践，这个问题可以通过，过4+1视图，软件各阶段对应关系来回答。