最近在做项目阶段性的测试和上线，还有指导实习生做项目，框架计划虽然一直在进行，但是都是很基础的研究工作，并没有太系统化的成果，所以也就一直没动手写这个系列。
说实话，我在选型上犯了难。一直以来都用的是传统的三层架构，一是比较成熟，十多年前上大学的时候已经在学习并运用了，而且后来开发的几十个项目中并没有出现太多的问题，当然也许是和没什么大型的项目经历有关。二是三层已经很符合项目工程化的概念，无论是运用TDD还是DDD，总有新人理解和上手不易，实际操作效果不明显的问题。
关于第二点，我可以举去年进行的一个项目例子来说明。去年开始了一个新项目，因为当时我负责需求整理和业务分析，框架是公司的架构师负责的，他也用的是3层的方式去搭建整个架构，利用脚本从数据库生成基础代码，手动编写业务逻辑和页面逻辑，其实这个架构很简单，我当时大概看了下，没什么问题，就确认使用了。项目开始后进行了人员的扩充，有多年经验的老程序员，也有还没毕业的实习生，开始之前，我们给新员工进行了短暂的框架培训。说实话，效果并不是很好，虽然是传统的三层，但是我们还是对框架的一些实现做出了约束，过后开发中发现即使是有经验的程序员，也并没有严格按照约束来进行开发。比如将大量的业务逻辑放在controller，或者DB层放置了不少查询逻辑。如果是在没研究新的框架以前，我并不会觉得有太多问题，顶多在codereview的时候，把比较严重的地方进行重构。但是我在后来思考的时候想，架构不是应该更多从技术角度去进行约束，人为的代码控制只是辅助吗？也就是说，如果架构搭建得好，程序员都应该会觉得在这个层或者模块内实现业务逻辑很方便，在另一个层次模块内进行展现更合适.
做菜不实际掌过勺就没办法注意火候，所以在确定最终选型前，我还是从最熟悉的方式做起.看看从三层过度到TDD或者DDD应该是怎样的。我建立了如下的项目结构
使用了部分园友使用的搭建演示框架的组件——EF，Unity或者autofac，automapper，看看搭配起来合不合适。
1.数据层。和往常一样，提供最基础的数据访问服务
2.业务层。业务和大部分的数据转换放置在这里
3.基础设施层。提供数据实体映射以及生成模板，转换的数据模型，还有部分基础的非逻辑性的常用函数以及部分初始化数据
4.展现层。mvc,测试工程等等
下一章节先从数据层说起