首席架构师汪洋坐镇，欢迎大伙提问啊：软件架构连载讨论之一：正确认识软件架构

napleon

我的理解就是：所谓架构就是将需求拆分为子独立的子系统，并建立其这些子系统之间的纯逻辑系统模型。而通过一些策略和方法，将这些子系统抽象成一些功能模块，并建立起基于这些功能模块所提供的接口的调度关系，就是设计。而将这些模块接口所要实现的功能用代码描述出来就是编程实现了。这三者并非有明显的层次关系，但是初如行者，首先强调的是高效编写这些出这类接口实现的技巧。

napleon

而team leader则需要熟悉各种设计模式，能将架构模型中的子系统抽象成相互独立又基于接口松耦合的逻辑模块的能力。

yanyangtian4502

回复 43# napleon


    架构不仅仅只是考虑逻辑的层面，或者说 架构不仅仅只是考虑代码方面的东西，其实更多的时候是综合的考虑：人，资源，技术，投资者的利益等

yanyangtian4502

所以一个架构做出来之后，我们可以看到的可能就是一些文档，代码等，其实这些都只是架构的一种反应形式，架构！=编写文档！

yanyangtian4502

不同的人对架构有着不一样的理解。无论是在建筑行业、软件行业，还是在网络或书本上，“架构”一词有着各种各样的解释。在编程的世界中，很多对架构的解释都是从技术的层面来定义的，而且在不同的技术或平台上面，对架构的定义又不太一样，甚至有些定义和理解失去了其原本的核心意思，这就使得部分架构学习者感到迷茫。

如果认为“架构”是一个简单的实体，能够用一份文档或一张图纸来描述，那么你就错了。确实，架构师在为系统创建架构时经常要做出很多与设计相关的决定，而且会以用文档的形式记录下来，但是架构和文档又不是等同的，之所以要以文档的形式保存，主要是为了便于以后对这些设计决定进行审核和修改，并且将其作为构建软件时的约束和指导。

snow888

所以一个架构做出来之后，我们可以看到的可能就是一些文档，代码等，其实这些都只是架构的一种反应形式，架 ...
yanyangtian4502 发表于 2011-10-17 14:54

    严重同意啊。

架构就是对将要实现的系统的抽象话，是将要实现的系统的模型化，这中间即包括物理的，也包括逻辑的，还包括数据层的。

俺不同意某些将应用层的组成方式也归类于架构的范畴，俺觉得那应该是系统需求分析的一部分，俺理解的需求分析包括业务需求方面的分析，也包括为实现业务需求而对应用的功能模块的预安排部分。

snow888

晕，又进这帖子了。

AD8018

我的两个问题，
http://bbs.chinaunix.net/redirec ... 48&pid=21521478
能否就此两个具体问题解惑一下，谢谢

yanyangtian4502

回复 50# AD8018


    ok，我看看

yanyangtian4502

言归正传。
我对系统架构上面有两个疑问，楼主能帮指点一下？

1. 无重构没有好架构

   开发一个项目之前，各方面都想的不错。
   然而，随着需求的深入和增加，缝补的东西变多，ctrl-c/ctrl-v的东西变多。
   最后，要么忍受，要么狠心重构。
   于是，在我的概念里，就有了这句话 -- 无重构没有好架构

   如何做到不重构，仍有好架构？

回答：在项目开始之前，其实我们对需求和功能不是完全清楚的，这个时候，不会，也不可能将系统架构全部做出来。此时只是的设计是最简单的，采用接口编程的形式，将每个层之间的衔接搞好，便于后续改动！
改动是在所难免的，很多人认为：架构师就是在开始就将整个系统的架构全部设计好了，其实这是不对的！架构师的在刚刚开始的时候，做出的架构也很简单，目的在于尽可能的是的以后的改动波及到的代码更少。然后，每次的项目迭代，不断的将架构完善，重构也是一个必要的步骤（很不幸的是，在后续的迭代中，很多公司和人员都不愿意花时间去重构了，认为很花时间，并且没有效果）

2. 多一层架构，多一层混乱

   以前迷恋封装接口之类的东西。其目的，原本是统一和简化接口，
   最后，还是随着需求的深入和增加，
   统一和简化的接口，变成了多增加的接口。

   为什么？其实你没有简化接口，原本的接口还在。
   你要强迫别人不用吗？很难。

回答：设计其实就是追求的简单，从实际出发，不做无谓的假设（如果要做假设，那么就要对该项目的领域很清楚）！很多人在设计的时候，为了显摆自己很牛或处于其他的原因，把项目设计的N复杂。

   Win32 API是一层接口，c库是一层接口，mfc是一层接口。
   哪一层的封装，都使事情朝着简单和混沌两个方向发展。
   简单能理解，混沌呢，比如
    CreateThread -> beginthread -> AfxBeginThread
   用的不好会要命。你觉得封装的结果，使事情变简单了，还是变复杂了？

   这是接口设计的例子。反应到设计架构上时，俺就如履薄冰，尽量避免无畏的封装。
   封装的不好，还不如不封装。
   最终的结果，就是你的项目，变成一坨谁都不愿意碰的东西。

   如何避免以上的窘境？

总之：走简单路线，在开始的时候，设计一个基本的几层逻辑架构就行了，并且每层采用接口实现，后续项目不断的迭代，不断的改进！不要无谓的做很多的假设（不要说：以后可能会这样等话语）。也不要花尽心思想：这里采用什么模式，那么采用什么原则！等到出现的时候再改！
记住：小步骤，多行动，不断的改动！没有万灵丹！