之所以阅读《架构之美》这本书作为阅读的课外读物，原因是为我在专业道路上制定一个小的目标——软件架构师。在初次接触软件架构之后，我并不懂软件架构是干嘛的，以为不都是编程吗，有什么不同之处，但是在后来的慢慢学习中我改变了自己的观点，架构有着很大的作用，架构有着它的美之处。
在书中我并没有特别关注到架构定义或者是如何创建架构之类的话，特别吸引我眼球的是书中问到的一句话：软件架构的设计关注的是什么？答案不是系统的功能，软件架构师首要关注的不是系统的功能，而是关注系统需要满足的品质，品质的关注点指明了功能必须以何种方式交付，才能被系统的利益相关者接受，其中典型的利益相关者和关注点如下：
投资人：想了解项目是否能够在给定的资源和进度下圆满完成；
架构师、开发和测试人员：首考虑的是最初的构建和以后的维护与演进；
项目经理：组织团队，指定开发计划；
市场人员：他们想通过品质特点实现与竞争者的差异化；
用户：最终用户，系统的管理员，安装、部署、准备和配置的人员；
技术支持人员：关注的是帮助平台电话呼入的数目和复杂性。
那系统的品质又有那些呢？其实就是我们通常所说的性能、安全、可伸缩性等都会被定义的很好，而诸如可变性，可维护性，可用性等并没有详细规定，架构师在这方面应该更要加深理解，以更好的满足品质的期望。
所以架构师的第一项任务就是和利益相关协作，理解这些品质的关注点和约束，并为他们排列优先级。
具体的系统还会有其他的关注点：
功能性：产品向它的用户提供哪些功能？
可变性：软件将来可能需要哪些改变？
性能:产品将达到怎样的性能？
容量：多少用户可以并发使用该系统？该系统将为用户保存多少数据？
生态系统：在不是的生态环境中，该系统将于其他系统进行哪些交互？
模块化：如何将编写软件的任务分解为工作指派？特别是这些模块可以独立的开发，并能准确而容易的满足彼此的需要。
可构建性：如何将软件构建成一组组件，并能够独立实现和验证这些组件？哪些组件应该复用？
产品化：如果产品将以集中变体的形式存在，如何开发一个产品线，并利用这些变体的共性？产品线中的产品以怎样的步骤开发等等。
书中介绍了什么样的的架构才算是美丽的架构，美丽的架构在开始时，要关注其实用性，好的架构应该是每天被很多人使用的；使用架构之前，我们还要考虑它必须要能够被构建（可构建性）；接下来就是关注架构的可持久性，好的架构应该能够经得起时间的考验，能够考虑到未来的变更，允许期望的修改；最后，要寻找一些能让人高兴的架构（开发人员、测试人员、用户等），这就要求架构必须满足概念完整性，这样的架构才易懂，易用，才会做到简单而又不过于简单。