标签：des style color 使用 strong sp 问题 on c
个人觉得本书概念太多，软件的架构和开发不是概念拼成的，一些经验性的东西用合适的词描述就行。
所谓风险驱动，其实就根据项目情况选择合适的设计力度，避免过度设计。而对于复杂的软件系统，精心设计还是非常重要的，在开发前和开发中都会有设计的问题。
另外，对于一个软件工程师，对一些架构模式需要有些了解，在脑海中构建所谓的“概念模型”，而每个模型都是一定的抽象和受到一些约束。
还介绍了领域模型，设计模型，代码模型，封装和分割，模型元素（组件），模型关系。
架构风格，就是所谓的概念模型。
第二部分值得一看。
最核心的问题应该是：“对一个特定的系统，应该做多少相应的架构设计工作？”
一个答案：“恰如其分的架构”。
Fairbanks认为，决定架构工作是否充分的核心标准是，看它是否能够降低风险。如果设计中的风险很小，就不需要做多少架构工作。如果系统设计有很大的问题，架构就是一个很好的工具。本书真正站在工程的角度，从成本和收益方面来选择技术。尤为可贵的是，它通过关注风险的降低，平衡工程上的收益和进行架构设计的成本，从而获得最好的结果。
很自然，还有很多派生出来的问题需要回答。
哪些风险是最好通过软件架构来解决的？
如何采用架构设计原理来解决一个设计问题？
哪些架构承诺要写下来以便其他人参考？
如何确保架构承诺被实现者所遵循？
为了解决软件的复杂度及规模增长带来的问题，解决思路牵强地归纳为三类：分治、知识、抽象。
开发者把问题分割为规模更小且易于处理的若干子问题，
这样他们就可以运用相似问题的知识来解决某些子问题，
而且使用抽象有助于他们进行推理和判断。
我们在构建系统时，应该选择最符合当前需求的架构，并在该架构的框架下实现功能。
概念模型——抽象与约束
本书建议使用风险(risk)来权衡实施架构的度。
一、风险驱动的软件架构
二、架构建模
经典的模型结构：领域模型(domain model)、设计模型(design model)与代码模型(code model)。
领域模型对应于真实世界中的事物，
设计模型是针对正在构建的软件所做的设计，
代码模型则对应于源代码。
我们还可以构建一些额外的模型，用于展现特定的细节，并称之为视图(view)。这些视图可以归为不同的视图类型(viewtype)。
构建封装边界是软件架构的关键技能。组件或模块的用户通常会忽略内部的工作机制，而将精力放在解决其他难题上。对于封装好的组件或模块，可以自由地改变其内部实现，而不会影响到它们的用户。
标签：des style color 使用 strong sp 问题 on c
原文地址：http://www.cnblogs.com/549294286/p/3995221.html
