良好的架构大致包含以下部分，只有尽可能多的考虑到以下方面，才可能成为良好的设计。

 

l  是否覆盖了所有的需求中提到的功能

架构设计一定要涵盖当前所有的需求中提到的功能。

l  数据设计(数据库设计)

数据表的设计，没张表尽可能原子性，使得系统在储存上面，每张表也有各自的存储职责，与类的design是一样的，职责单一，不过有时也适当冗余，因为软件设计基本的原则是简单。

l  主要模块、类的划分与职责的分配

模块的划分、类的设计，在初期应该就要对系统的职责有明确的分配，对系统进行解耦，接口独立于实现，针对接口编程。

l  核心业务

核心业务应当单独拉出来考虑，毕竟是客户最关心的部分，这部分或许对UI，性能上都会有一套独立的策略。

l  UI、业务逻辑、数据结构、算法分离(算法也可以与数据结构合为一层)

UI需要专业美工来设计，制作，并与客户不断进行确认，初期就要完成的，有时候，UI会带来很大的复杂度，也是架构师需要关注的一个部分，进可能使得展示与业务逻辑分离，应对变化。数据结构和算法有时候也可以实现分离，实现更大的灵活度，例如c ++编程语言中的STL。

l  资源管理(线程、数据库连接、网络传输，句柄)的使用量，如何管理这些资源。

例如数据库连接，为了保证每次连接都得到释放，我们需要对其进行一个封装（所谓的dbHelper），网络传输也一样，协议层，连接层，网络代理，也可以根据业务的复杂度弄一个代理工厂。

l  性能

性能是很重要的。有时候不得不牺牲良好的设计来换来必要的性能。这也是我们初期需要规定好的，系统支持多少用户同时在线，用户每次操作的响应时间是多少等等。

l  安全性

身份验证。一个最基本的安全验证机制是身份验证，通常一个系统，一个程序都会需要一个身份验证，来保证系统的安全性。

接口安全。比如暴露一个web service，那么就要保证调用者的身份是安全的（例如IP地址白名单机制）。

网络传输安全，通常网络传输过程中是需要加密的，当然要看系统的安全性要求是什么程度的，有时也是不必要的。

l  需求的可伸缩性

需求是经常变化的，经常添加的。因此，目前架构能否适应需求的变化和伸缩是很重要的。

l  异常处理

为可能出错的地方捕捉异常，尤其是多线程、并发IO、数据库操作等等。

l  LOG

根据不同的需求，不同的场合，把日志分为几种，通常有两大类，一类是正常的事件性日志，另一类是异常日志。

l  容错性

系统接收到了错误的输入时做出的响应。

l  健壮性(系统出错之后可以继续运行的程度)

系统出错之后应该确保变化的部分不会扩张，如果系统设计良好，很好的封装了变化，隔离了系统的实现细节，那么系统就相对健壮。

l  最底层架构是独立于语言的

每一个好的架构都不应该依赖于编程语言的。

l  有哪些功能可复用以前的代码

有些模块是可以复用的，也可以根据项目成本来决定是否需要购买一个模块。

l  本地化

软件是否需要本地化，这点要根据需求来定。