尽量少的前言
虽然写了N年代码了，但总觉得什么东西都是囫囵吞枣，无法尽得其精髓。最近整理了一套心目中的架构，如有错误之处，烦劳不吝指正，老胡在此不胜感激！！
第一篇 我心目中的架构
做了无数个系统，写了无数个项目，有几个问题始终困扰着我。
总是重复做着同样的功能，比如组织架构，比如权限模型；
代码质量总是无法得到根本性的保障；
大量的功能性代码重复，没有被很好地抽象出来（其实就是设计模式没有被很好地利用起来）；
过一段时间后修改代码很困难，因为代码风格总是随着时间在不断变化，并且大部分时候代码都是来自好几个人的。
我想有一个架构，它可以有以下一些特性：
1、利用EntityFramework实现ORM特性，在设计及编写项目时，思路能最大程度地保持在业务本身，而不用跳出到数据库设计上去；
2、借鉴DDD的设计思想，将业务逻辑封装到聚合里（实际上我是很想完全采用DDD的，但是啃了半天书，因为没有实际项目的实践，在领域事件上仍觉得很模糊，并且对于聚合的实际应用方式也不是很清晰）；
3、将通用性的一些操作，比如增删改查，抽象出来，放到业务逻辑的核心层去实现，每个业务逻辑不用再自己实现。这样上层重复代码量将会少很多；
4、规范一些基本操作的代码写法，在最大程度上确保上层代码质量的可控性；
5、通过SOA模式，实现包括一站式登陆、权限判断、通用（常用）模块的独立运行；
6、业务逻辑层不局限于对某一特定模式的UI层的支持，它应该能够广泛地支持WEB、MVC WEB、WINFORM、MOBILE（ios or android）端的调用；
总之，通过这个架构，我想能够在编写具体业务功能的时候使用尽量少、尽量标准的代码来实现。
基于此，我对整个架构进行了如下一个层次划分：
01 UI 层代码：这里是各种客户端的代码，我在其下做了个01.01 MVC WEB Application的目录，如果有其他的客户端，可以在这下面实现，比如增加一个 01.02 WIN FORM Application。
02 SOA：为界面层提供数据的服务层，这一层实际上是一个数据中转层。我将业务逻辑中的各个聚合都通过SOA暴露给客户端，那么不同的客户端都可以通过统一的方式来对系统进行访问了，实际上这一层也起到了一个防腐层的作用。当然，如果是本机运行的WIN FORM模式，或者不希望采用SOA模式，也可以在UI层直接调用业务逻辑层。
03 Business Logic：业务逻辑层，在这里面对不同的业务逻辑按照DDD的设计思想，设计为不同的聚合（Aggregate），这一层也是需要我们自己编写的。SOA层与这一层进行通讯。
04 Model Logic：模型层，也就是实体层。我将业务中的实体对象单独拆分出来，没有和业务层放到一起，因为在UI层里都会用到各个实体的定义，而业务逻辑层我并不想直接交给UI层去使用。UI只需要知道自己当前使用的实体有哪些属性可以使用就好。实体我采用的是充血模型，包括自我验证等特性，这个会在后面说到。
05 Business Core：业务逻辑核心包（代码），严格说来，带Core名字后缀的都不是单独的一层，只是一个基类。业务逻辑层的代码都是从这个东西派生出来的，这里面包含了一些基本的、通用性的业务操作。
06 Model Core：实体层核心包，同上，我在这里给定义了集中标准的实体模型基类，所有实体都需要从这些标准基类中派生出来。同时在这里实现了一些实体的克隆、验证等通用方法。
07 DATA：数据持久层。一直很纠结这里究竟要怎么做，尤其是对不同数据库的支持上，最后因为自己一直使用SQLSERVER，所以这里直接就通过EntityFramework来实现了，EF本身就支持很多种数据库，但没测试过，至少在我的需求内，SQLSERVER是完全没问题的。
08 General：通用描述定义，这里不能称为一层了，我把一些常用的数据类型进行了标准化，实体类在使用这类属性的时候直接从通用描述定义里取得就行，这样利于实现数据格式的标准化，比如实现了数据锁定状态描述信息、数据过期状态描述信息等。
09 Common：工具类，就是各种Helper，这里的工具可以根据需要随时增加。
10 Reference Lib：引用的第三方类库统一放到这个目录下，方便查找。
11 Solution Documents：项目文档什么的，都放这里就好。
12 Test Projects：单元测试代码
13 Publish：项目发布目录
额，下一篇从最底层写起...