【PaPaPa】这个项目是以技术分享与研究为目的而做的，并非商业项目，所以更多的是提供一种思路，请勿直接在项目中使用。

上一篇隐藏开源项目地址实属无奈，为了寻找一起做这件事的同伴不得已刷了一天推荐，在此希望大家能够理解。

从此篇开始将完全公开项目地址以及所有项目中涉及到的细节，包括文档、讨论过程、设计思路、实现方法全部整理出来写成一个系列，这个将在后续文章中一一揭开，敬请期待。

本项目与博文系列将秉承着“授人以渔”的方式写作，尽自己绵薄之力为C#出一份力以回馈我从C#中得到的快乐和生活上的改善。

同时因为本项目不涉及分布式和大数据方面的内容，所以本博文系列也不会有这方面的内容，即便是应用了Redis，也只是以缓存的方式来使用。

最后本着不想误人子弟的想法，欢迎各位同行斧正错误！

 软件架构分逻辑架构、物理架构、系统架构。

一般情况下系统架构师会出起码包含以上3个部分的文档，而部分分工明细的公司，物理架构关于服务器配置与网络的章节由运维部（或其他类似职责部门）来补充或修改。

有此可以看出一个合格的系统架构师，他/她的知识广度是很恐怖的。

当然本文并不是一个维基百科或百度百科，所以只是浅谈即止。

首先明确一点的，万能是因为它是一个兼顾与取舍的博弈，没有一个系统架构可以拍着胸脯说：我可以应用到任何场景。

系统架构与业务有着强烈的依赖关系，业务左右系统架构，而系统架构有时在特殊情况下也可能会影响业务做适当调整。

既然说到业务左右系统架构，那么很明显，要先有业务才有系统架构。

需求文档是业务的可视化输出。正常情况下此文档由产品经理或需求专员来撰写，用来描述软件所包含的业务。

下面我们只简单的拿个【PaPaPa】项目在建立时‘老虎’随手画的2个脑图，现在的需求文档已经从v0.1-v0.4了，目前正在整理新版中，预计下周会出。

上面2副只是其中讨论过程中出现的比较典型的而已，当然正式的需求文档肯定不会是这个样子了。

 从上面图中可以看出大概分为Web端和移动端两个大的部分，

由于急着赶出一个雏形，我们当时确定了移动端的放到后面再做，所以暂时仅仅考虑了扩展而没有规划。

虽然延期了，但是系统架构搭建时必然是要考虑到这点的，否则后面的修改会让你很是头疼。

解决方案文件夹有助于帮助我们将类库进行归类，比较常见的是类似下面这样

当然，根据每个人的喜好命名会有所不同，有的项目需要可能会没有Test，也有的可能会把Business和Core合并等等。

而我们的划分则是上图这样，区分业务和核心是因为核心层提供了底层的数据操作。业务来组装这些操作来满足业务需求。

而这一块则是配合上面说到的，将来要做移动端，而移动端业务跟Web端是有一些差别的，不论是从接口数量还是接口内容都会有出入。

以业务层为例，PaPaPa.Web.* 为一组。

其中PaPaPa则是项目名称，Web则是分属哪一个业务模块，那么移动端的命名呼之欲出的方式则可能是 PaPaPa.Mobile.*

由于其他分层并没有什么可想说的内容，所以其他的就忽略了。有疑问可单独提出。

我们先简单了解一下：

核心层：被业务层包围，给业务层提供底层操作支持，如DB、缓存等。

业务层：借助核心层提供的功能封装不同模块的业务。

基础设施层：给所有的层提供最基础的底层支持（不包含任何业务逻辑），以PaPaPa项目为例，包括但不限于：通用缓存操作（缓存监控）、通用类库、DB操作、通用的模型与实体映射、缓存操作。此层还应该有很高的移植性，在创建新项目时，此层可直接拷贝使用是一个隐含的标准。

在创建新的类库时，根据当前类库所承担的责任将其放到对应的层级中是对一个类库在系统中所处角色的一个重要的标识。

如果你不小心把一个处于核心层的类库放到业务层，后果则是出现各种冗余代码，因为不同业务模块间按理说是不允许互相重用的，除非你再创建一个 PaPaPa.BasicBusiness.* 类似这样的一个专门归类基础业务的模块。

当然这只是从合理角度来说的，如果设计者到后期无法维护自己心目中的系统架构时，则会出现各层级交叉调用的一种混乱局面，而那时，项目的维护成本将会很高！

有不少同行看到我的类库后觉得类库数量太多，有些类库内没几个类表示不解。

其实类库内类的数量多少不是关键，关键是类库的职责是否有明确划分，否则就会变成各个功能放在同一个类库。

一方面是会导致类库内文件夹层级过深，另外一方面则是升级时不相关业务会因为升级而中断，最最总要的一方面则是加大系统分层的难度，因为一个功能庞大的类库很可能会跨多个层级。

下面是PaPaPa项目中每个类库所担任的职责，这只是众多分类方式的一种。

只要你在做类库划分时，按照一定的规则来归类即可。

这能让开发者更明确的知道系统搭建者的意图。

这只是这个系列的一个开篇，后面会把我们在写这个项目过程中的一些比较重要的环节以及实战经验加入到其中。

当然会包括很多人关注的缓存决策，如何在不破坏系统搭建意图的情况下加入新的底层支持。

简单说下，缓存决策又分自动决策和手动决策两部分，底层支持跨了2个层级，且因为灵活性问题部分区域为何放弃自动决策。

当然了，这个说起来名字很高大上，其实也就是普通的C#语法的一个组合罢了。

最后，源码地址：http://git.oschina.net/doddgu/PaPaPa

【PaPaPa】系统架构搭建浅析 - 人人可以搭架构