【IT168 技术文章】
软件构架是一个容易理解的概念，但多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难，在设计中更容易忽视软件架构的巨大作用，所以我将在以下的内容中解释什么是软件架构以及如何提高架构的性能等软件设计中的容易被忽视的问题。
一、什么是架构
1. 和架构相关的几个问题域
架构需要解决的非业务问题域包括如下：
A 系统目标：系统性能，稳定性.
B.项目目标：开发成本，质量
C.项目过程：需求的不确定性和开发过程的团队协作性
不同的问题域，解决之道也不相同!而同一问题域的不同层次的要求，解决之道也不尽相同。
2. 什么是架构
架构到底是啥，愚以为下面的这段英文描述的很清楚。
That's like asking, what is culture? Culture is the way you do things in a group of people. Architecture is the way you do things in a software product. You could argue by analogy, then, that architecture is to a software product as culture is to a team. It is how that team has established and chosen its conventions，
Which leads us inevitably to the question of “goodness”? How do you know if an architecture is good? Consider an architecture that isn't built using a strong domain model, and instead relies heavily on stored procedures. That might be OK, or it might not be OK. You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures, right? So an architecture is some reasonable regularity about the structure of the system, the way the team goes about building its software, and how the software responds and adapts to its own environment. How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.
The system architecture determines how hard or easy it is to implement a given feature. Good architectures are those in which it is considered easy to create the features desired. In that the way to judge whether an architecture is good is whether the architecture is good for the purposes to which it is applied.
The definition of goodness has to be related to fitness for purpose. Is this glove good? I don't know. What are you doing with the glove? Are you throwing snowballs, cooking barbeques, or playing golf? There's a set of changes that are going to occur to a software system over time. Probably the utilitarian or most useful definition of goodness is the answer to this question: are the changes that will keep this system successful in this domain in this product line relatively easy? If they are, then it's probably a good architecture.
