架构漫谈读后感

       一直以来，我们耳边就有人谈论各种架构，比如说知识架构，社会架构，营养架构。在软件工程中，也有架构这么个概念，在了解架构以前，我一直停留在字面意思来，认为架构就是一种结构，一种解决问题的通用结构。按这个结构搭建，就可以使代码更加简单，高效。在前几天的课上，老师给我们时间阅读了一篇文章《架构漫谈》，作者用通俗的语言，和一些例子，介绍了架构的概念，以及架构的设计理念。

       在作者看来，架构，就是：

1. 根据要解决的问题，对目标系统的边界进行界定。
2. 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
3. 并对这些切分出来的部分，设立沟通机制。
4. 根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

　　举个例子，在一座小岛上，生活着一些人，为了生存，他们每天都要忙于衣食住行，但是有些人，他们善于种田，有些人擅长缝补，他们便联合起来，各自只做自己擅长的事，并相互扶持，原本需要一天的工作，半天就完成了。以上面这个例子为例，现在有一件复杂的事情需要进行，使用架构，就是把问题进行分工，交由不同角色完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，这样一来，解决问题的效率肯定是会大大提高。一句话概括就是，复杂问题简单化，简单问题流程化。

　　软件工程师如何进行合理的架构呢？首先，要熟悉建设单位，定义职能域。在需求调研阶段，架构师首先要全面了解用户中所有人员的需求，首先要了解建设单位的组织机构、业务关系，并根据建设单位中的一些主要业务活动领域，研究定义职能域，这是第一重要任务。职能域是用户功能规划的抽象，应符合建设单位内部各种业务的逻辑关系，而不是现行机构部门的翻版，一经识别，就要保持相对稳定。研制职能域模型时，需要特别注意，要自顶向下规划，并把握好设计职能域的数目；注意用户需求的主次关系，按照重要性、优先级进行权衡取舍。   

　　其次，要详细调研各项业务过程及其功能分解。调研前，架构师要对调研的内容事先准备，针对不同管理层的用户询问不同的问题，列出问题清单，将操作层、管理层、决策层的需求既联系又区分开来，形成一个金字塔，使下层满足上层的需求。调研时，要收集用户工作中涉及的所有内容，如各种单据、报表、处理规则，再将其串成流程图，以流程图为主线，同时把握以下方面：

（1）该流程中是否存在不必要的环节；

（2）流程是否可以简化，是否可以省略一些环节；

（3）流程中的每个处理环节是否起到了增值提效的作用；

（4）哪些流程可以并行处理。

　　最后，软件工程师要考虑长远，将来用户需求的变化是很正常的现象，如果仅仅着眼于现在，而不对将来有所考虑，软件的寿命便不会长久，要将以后可能的变化考虑在内。