1.
n-Layer Design & Development

2.
Agenda
• 引子、Why n-Layer、Why MVC
• Domain、Data、DDFx
• HelloDDFx Demo
• Q & A

3.
引子：以下哪些关于经典三层架构的描述是正确的？
• 1、User Interface（UI）层一般指Web 前端，主要负责用户交互
• 2、Business Logic（BL）层一般指业务逻辑，可以包括UI 逻辑
• 3、Business Logic（BL）层一般指业务逻辑，不可以包括UI 逻辑
• 4、Data Access（DA）层一般指数据访问，主要负责关系数据库
交互
• 5、三层架构的优势是把代码分散到不同模块中，以方便程序员
编写不同的部分，实现代码重用

4.
引子：以下哪些关于经典三层架构的描述是正确的？
• 1、User Interface（UI）层一般指Web 前端，主要负责用户交互
• 2、Business Logic（BL）层一般指业务逻辑，可以包括UI 逻辑
• 3、Business Logic（BL）层一般指业务逻辑，不可以包括UI 逻辑
• 4、Data Access（DA）层一般指数据访问，主要负责关系数据库
交互
• 5、三层架构的优势是把代码分散到不同模块中，以方便程序员
编写不同的部分，实现代码重用

5.
引子：关于简单& 复杂的3 条语录
• 代码像首诗
– Code is like a poem
• 设计是一场与复杂性的战斗
– We believe designing systems is a fight against complexity.
– Most of the time the best way to fight complexity is by not creating it.
• Coding 是件“艰苦”的事，唯一的办
法是享受它；如果Coding 已不能带来
快乐，就考虑“停止”它。

6.
引子：应对复杂问题两大策略
• Divide and Conquer (分而治之)
– D&C 侧重战略
– 典型案例：递归、Quick-Sort、Map-Reduce、etc.
• Separation of Concern (分离关注)
– SoC 侧重战术
– 典型案例：S.O.L.I.D.、n-Layer、TDD、DDD、MDA、DSL、etc.
• 业务复杂vs. 技术复杂
– 业务复杂应对策略：OO、DDD、四色原型、etc.
– 技术复杂应对策略：n-Layer、n-Tier、Distributed、etc.
– 业务+ 技术复杂应对策略：DSL

7.
携程架构设计“S”之Case Study
• S  Simple & Suitable & Scalable
• 以CMessaging 为例，它主要解决哪个S？
• 请排序：Simple, Suitable (balance), Scalable (10x)？

8.
引子：面向对象开发三大名言
• 抽象不变，封装变化
– XXX Pattern
– YYY Framework
• 面向接口编程
– 低耦合
– S.O.L.I.D. 中有3 条与接口紧密相关
• 优先使用组合
– 高内聚
– Biz App 慎用继承，why？

9.
Case Study：Factory + new() ?

10.
Case Study：低耦合?

11.
另一低耦合案例：BLL 访问Session？
SoC-style 做法：在Controller 中
访问封装过的Session Utility

12.
Ctrip 2013 RCA 特点：Non-Functional Bugs

13.
开发人员的困惑：多快好省？
• 多 最近项目有点多，怎么都是最高优先级？
• 快 业务要求快点上，项目经理都是催命三郎
• 好 老板要求质量高，架构师说不能违背设计
• 省 加班加点人手少，copy-paste 代码最省心
• 结论：多快好省催人老，开发效率难提高

14.
10x 基础：Design + LPT + 开发效率?x
开发人员术业有专攻
开发效率大幅度提升
减少技术犯错的概率
有时间关注性能问题
有可能实现10x scalability 目标！

15.
开发效率：如何实现【术业有专攻】？

16.
Why n-Layer ? Why MVC ?
• 分离关注，分离依赖（SoC）
– 因为分离，所以可扩展（Open-Close 原则）
– 因为分离，所以可单独测试
• 传统n-Layer 或Web Forms 架构
– 分离部分关注，分离部分依赖
– UI/View 分离仍然难以解决
• MVC 架构
– 尽可能分离一切关注，尽可能分离一切依赖
– UI/View 是最难分离的-> Controller

17.
传统3-Layer & 3-Tier 的问题？

18.
传统3-Layer & 3-Tier 的问题(PetShop)？

19.
传统3-Layer & 3-Tier 的问题(PetStore)？

20.
问：传统n-Layer 两大问题？

21.
答：传统n-Layer 两大问题？
#1：高耦合 跨层调用依赖实现
#2：低内聚 业务逻辑各自为政

22.
n-Layer 反面案例，评估需谨慎
• Northwind
– Model 诲人，SP 毁人
• Duwamish
– Layer 诲人，SP、DataSet 毁人
• PetShop
– Factory、POCO 诲人，【伪分层】毁人 毁人之王！
• Microsoft Domain-Oriented N-Layered App
– 典型Overdesign 【简单问题复杂化】之“楷模”！

23.
MVC 的因果循环 让你爱上测试！
• 为什么要MVC？
– 实现更全面的关注点分离（SoC），简单说是职责分离！
• 为什么要（更全面的）关注点分离（或职责分离）？
– 更容易单元测试、接口测试、压力测试、性能测试、etc.
• 为什么要（更容易的）xxx/yyy/zzz 测试？
– 体现更健壮的设计理念（TDD）！
• 为什么要（更健壮的）设计理念？
– 创造出更高质量的软件产品！
• 为什么传统n-Layer 或Web Forms 创造不出高质量软
件产品？
– 不是创造不出，而是要付出很大代价（自动vs. 手工，简单vs. 复杂）！
• 为什么MVC 可以创造出高质量软件产品（为什么要MVC）？

24.
问：爱上单元测试两大障碍？

25.
答：爱上单元测试两大障碍？
#1：外部依赖(container, db, service, io, etc.)
#2：体力运动(validation, comparison, etc.)

26.
答：单元测试两大障碍解决方案！
#1：外部依赖 Mock (dll + service)
#2：体力运动 Case Generator

27.
问：What is Mock ? Scenario ?

28.
Mock Demo #1 – Interface Mock

29.
Mock Demo #2 – Http Context

30.
Mock Demo #3 – VS 2012 Fakes

31.
问#1：Mock 难以对付的场景？

32.
问#2：如何解决Mock 难以对
付的场景？

33.
Demo – 解决局部外部依赖问题
#1：获取当前应用登录者
#2：模拟Repository Layer

34.
Demo – Unit Testing Case Generator
Pex

35.
Unit Testing 是提高软件质量的源头之一，
SoC 同样如此，让我们看一个案例。。。

36.
SoC Case Study：战国铸剑(穿越场景)？

37.
Case Study：战国铸剑vs. 现代工业
辰凌莞尔道：“这些东西不能让外人知道，任何一
个诸侯国都不能泄露，这是咱们的优势，另外，我看白
家铸剑坊内的工匠师，又有许多工匠助手、学徒，来帮
助他共同完成一件兵器，比如说宝剑，剑身需要铸造、
锤炼、打磨，剑柄需要挑选上好地拓木，然后套入剑柄
外壳，用牛皮一层层紧紧地缠上去，然后制作剑鞘等等，
一套流程下来，需要太多人在一起共同完成，而且每组
至少有一个铸剑师、工匠师，对不对？”

38.
Case Study：战国铸剑vs. 现代工业
“是的呀，有什么不对的吗？”白若溪一双美眸紧
紧盯着庆忌，不知道他从其中看出了什么弊病。
辰凌轻笑着说：“因为这样一来，需要太多的工匠
师和铸剑师了，雇佣金太高，资源浪费，一个学徒最终
成为一个匠师，至少需要几年的时间，而且每个工匠师
的手法不同，打造出来的兵器一批批都不相同，很难打
造出品牌来。”

39.
Case Study：战国铸剑vs. 现代工业
“我在想，把这种师傅带徒弟的生产模式，改成流
水线作业，也就是说，打铁的、铸剑的、做剑鞘的、打
磨的、淬火的、还原的、装饰的一条工艺下来，各个工
序分开，分成不同的工坊，流水线式生产。”
“这样一来，学徒很快能上手，精熟自己工艺的活，
而且统一传授，统一掌握，打造出来的工艺也差不多，
以此类推，一柄剑铸造出来，由各个工坊配合，这样根
本不需要太多的铸剑师、工匠师带队了！”

40.
SoC Case Study：工程师标签？
#1：技术标签vs. 业务标签
#2：招聘岗位vs. 优先考虑
#3：开发团队vs. 咨询顾问

41.
回到Why n-Layer ? Why MVC ?
#1：创业团队vs. 稳定团队
#2：小微作坊vs. 研发中心
#3：模块包干vs. 技能拆分

42.
n-Layer 之特殊Layer：Cross-Cutting
• Security
– Authentication, SSO, etc.
– Authorization
– Validation
• Service
– Logging
– Caching
• Others
– IoC
– Transaction
– Monitoring, Alerting, SLA, etc.

43.
Cross-Cutting 有点烦，有没有好方案？
• Security
– Authentication, SSO, etc.
– Authorization  Demo #1
– Validation  Demo #2
• Service
– Logging  Demo #3
– Caching
• Others
– IoC
– Transaction
– Monitoring, Alerting, SLA, etc.

44.
问#3：Cross-Cutting 演示中的
共同点？

45.
Cross-Cutting 演示与语言发展的共同点？
• C# 1.0
– Attribute (Java 5 Annotation)
• C# 2.0
– Generics (Java 5 Generics)
• C# 3.0
– Linq, Lambda (Java 8 Lambda)
• C# 4.0
– Parallel (Java 7 Fork/Join)
– Dynamic, Functional Programming
• C# 5.0
– async/await

46.
C# vNext？Cross-Cutting vNext？

47.
问#4：Declarative vs. Imperative ?
What vs. How 
不局限于Cross-Cutting 
Domain-Specific Language (DSL)

48.
Domain、Data、Declarative、
DDFx

49.
Difference between Lib & Fx ?
• 理解#1：框架与类库都可以认为是一种基础结构，
而我们编写的代码是应用代码
– 若是基础代码调用应用代码，则这种基础结构是框架，
如：.NET CLR，ASP.NET MVC
– 反之，若是应用代码调用基础代码，则这种基础结构是类库，
如：.NET BCL，ASP.NET Web Controls
• 理解#2：类库是类的集合，与类库相比，框架和类
库有着相似的形式，即框架也往往是类的集合
– 类库的类之间可能是相互独立的，应用开发者希望使用任何一
个类时可直接调用它
– 框架中的各个类不是孤立的，其业务逻辑将不同的类“连”在
一起，在它们之间建立协作关系

50.
Difference between Lib & Fx ?
• 总结#1：框架通过封装处理流程的控制逻辑，使它对
开发者透明，来简化开发工作！
– 类库由现成的、供开发者用于构建应用的组件组成，但是，开发
者必须理解不同组件之间的关系，并编写处理流程代码把众多组
件组织起来
– 框架则不同，它通过预先把众多组件组织在一起的方式，封装了
处理流程的控制逻辑；因此，开发者就不用再编写控制逻辑来组
织组件之间的交互了
• 总结#2：Library 解决一个或多个问题，侧重复用；
Framework 解决一类问题，接近半成品，更关注架构
• 总结#3：类库的基因是new，框架的基因的:

51.
什么是Domain？
作为软件方面的专家（架构师、开发人员）和领域专家
（客户方业务人员、需求分析人员），所有人在一起创建
领域的模型，这个模型会统一体现两个专业领域的交汇

52.
什么是Data？
Data Files、Database、Data Service、etc.
SQL、NoSQL、AWS RDS、SQL Azure、etc.

53.
What’s DDFx ?
• DDFx 的第一个D 有两层含义：Data and Domain
• DDFx 的第二个D == Driven，意为：…驱动的…
• DDFx 的Fx == (Development / Design) Framework (and Tools)
• DDFx 理解#1：Data-Driven (Development) Framework
• DDFx 理解#2：Domain-Driven (Design) Framework
• DDFx 具体内容尚在不断完善中，但请记住：DDFx
不是万能的，所以，你要懂得：Context + Balance
• DDFx 中某些非关键技术将采用Tech-Talk 方式进行

54.
Domain-Driven Design Sample – 银行转账
• 方案#1：acct_a.Transfer(amount, acct_b_no)
– Using (TransactionScope ts = new TransactionScope())
– {
this.Remove(amount);
Account acct_b = new Account(acct_b_no);
acct_b.Add(amount);
ts.commit();
– }
• 方案#2：acct_a.Transfer(amount, acct_b)
– Using (TransactionScope ts = new TransactionScope())
– {
this.Remove(amount);
acct_b.Add(amount);
ts.commit();
– }

55.
Domain-Driven Design Sample – 银行转账
• 方案#3：acct_svc.Transfer(acct_a_no, amount, acct_b_no)
实现方：
– Using (TransactionScope ts = new TransactionScope())
– {
Account acct_a = new Account(acct_a_no);
acct_a.Remove(amount);
Account acct_b = new Account(acct_b_no);
acct_b.Add(amount);
ts.commit();
– }
调用方：
– acct_svc.Transfer(acct_a_no, amount, acct_b_no);
• 推荐使用方案#3  Domain Models & Domain Objects

56.
DDD 典型案例- 网上书店

57.
面向对象三大名言之DDFx 注解
• 抽象不变，封装变化 尽可能使用Generics
– XXX Pattern
– YYY Framework
• 面向接口编程 Cross-Layer 尽可能使用Factory
– 低耦合
– S.O.L.I.D. 中有3 条与接口紧密相关
• 优先使用组合 Domain Model 组合Domain Object
– 高内聚
– Biz App 慎用继承，why？

58.
HelloDDFx Demo #1：工厂与泛型
IRepository<T> 
LinqRepository<T>  RealRepository<T>

59.
DDFx 中几个数字
• 1 座工厂：DDFx Factory
• 2 个车间：Domain Model (N 产品线)
 Repository (N 产品线)
• 3 种贯穿：DTO  Domain Model Intf.  Repository Intf.
• 6 层架构：Presentation  Application/Controller 
Service  Domain  Repository  Resource
• 10 大前端：
– C/S：Console  Windows Forms  WPF
– B/S：ASP.NET Web Forms  Ajax  MVC / MVVM (ViewModel : DTO)
– RIA：Silverlight (.NET 子集)
– Device：Windows Phone 7 (Silverlight 子集)  iPhone/Android (Xamarin)

60.
图表样例- 1：Visual Studio 生成

61.
图表样例- 2：Visual Studio 生成

62.
DDFx 架构层次
• 整体架构：6 层架构+ 1 座工厂(DDFx Factory)
• Layer #1：用户表现层(Presentation Layer)
• Layer #2：应用系统层(Application Layer)
• Layer #3：服务表现层(Service Layer, 可选)
• Layer #4：领域模型层(Domain Layer)
• Layer #5：资源访问层(Repository Layer)
• Layer #6：资源层(关系数据库、外部服务、文件系统、etc.)

63.
HelloDDFx Demo #2
Webforms/MVC/Ajax

64.
DDFx 中几个理念和约定(1)
• Domain Design 分两个阶段
– Domain Model Design  低耦合 Boundary & Interface
– Domain Object Design  高内聚 Relationship & Logic
• Domain Service Interface : Domain Model Interface
– local call or remote call  对调用方透明
 local call  interface  local dll
 remote call  interface  svc  local call  interface  local dll
• Data Objects 有三种
– DTO == Data Transfer Object，贯穿所有Layers
– DO == Domain Object，默认采用充血模型
– VM == View Model，映射至DTO & DO

65.
DDFx 中几个理念和约定(2)
• 设计次序
– 1、Layer  Domain Model (Interface/Façade/etc.)
– 2、Domain Object (Granularity)
– 3、Data (RDBMS/NoSQL/Cache/File/Svc/etc.)
• 开发次序
– 1、Domain Object / Data 可以根据需要Mock
– 2、UI / Domain Object / Data 可以并行开发
• 测试次序
– 1、Domain Object / Data 可以根据需要Mock
– 2、UI / Domain Object / Data 可以并行测试
– 3、集成测试

66.
Interface Case Study
• 机票捆绑卖保险
– 方案#1：只提供机票方法
– 方案#2：既提供机票方法，也提供保险方法
• 酒店关键字搜索
– 方案#1：在现有查询方法上提供关键字查询功能
– 方案#2：新增一个关键字查询方法，内部完成调度
– 方案#3：由调用方分别调用关键字搜索、酒店查询方法
• 简单总结：
Interface Design
ϸÔòÁ½Ìõ

67.
Granularity Case Study
• 为何“Account、Cart”不合并到一个Domain Object？
– 理由#1？
– 理由#2？
• 为何“Discount”不合并到其它Domain Object？
– 理由#1？理由#2？理由#3？
– 理由#4？
• 为何“Item”聚合“Book”而不是反过来？
– 理由#1？
– 理由#2？
• Order Type 设计为Enum 还是Domain Object？

68.
Ctrip DDD Real Projects
• 度假供应商管理– 周啸洪、李少鹏
• 公共服务积分商城– 李小林、顾新春
• More complex business projects ?
• All complex business projects ?

69.
HelloDDFx Demo #3
WP/Android

70.
HelloDDFx Demo #4
Declarative-Driven Development

71.
Declarative to DSL  任重而道远！
• Declarative Samples
– Attribute
– Linq + Lambda
– Fluent Interface (jQuery) + Functional Programming (F#)
• DSL Samples
– SQL, XSLT, CSS, ABAP, MATLAB, etc.
– LINQ to SQL Designer, Entity Framework Designer, etc.
– Class Designer, Workflow Designer, etc.
– VS UML Diagram Designer
– CodeSmith, T4, etc.
– XXX Model Designer, YYY Domain Language, etc.

72.
关于应用软件开发的大胆推测(not YY)
• 应用开发4 个演进阶段
– Data-Driven
– Domain-Driven
– Declarative-Driven
– DSL-Driven + Factory-Composing
• 高效开发4 个努力方向
– Single DSL  Microsoft Axum (Demo #1), Microsoft Oslo, etc.
– Simple RAD  Dynamic Data (Demo #2), LightSwtich (Demo #3), etc.
– DSL + RAD  Microsoft Business Framework, Sculpture, etc.
– Software Factory

73.
回到10x 基础：Design + LPT + 开发效率?x
开发人员术业有专攻
开发效率大幅度提升
减少技术犯错的概率
有时间关注性能问题
有可能实现10x scalability 目标！

74.
回到开发效率：如何实现【术业有专攻】？
n-Layer Design 
n-Layer Development 
n-Layer Developer Role Model
UI Dev + Biz Dev + Data Dev + etc. 
Interface-Oriented Design/Dev/Testing！

75.
现状：熟悉某几个模块vs. 精通所有技术
建议：熟悉全组业务vs. 精通某几门技术

76.
n-Layer Dev Role Model 建议
• Presentation Layer + Application Layer
– MVC：View, Controller, ViewModel
– 具体技术：HTML, JS, HTTP, ASP.NET, etc.
– Service Consumer 技术：API/Svc/Queue/WCF, etc.
• Domain Layer
– MVC：Model, Domain Objects
– 具体技术：OO & DDD, Data Structure & Algorithm, etc.
– Service Provider 技术：API/Svc/Queue/WCF, etc.
• Infrastructure Layer
– 具体技术：SQL/Replication/SSIS/Job, DAL, IO, etc.
– Service Consumer 技术：API/Svc/Queue/WCF, etc.
• Cross-Cutting (Fx Team, Arch Team, etc.)
• Security, Logging, Caching, Monitoring, Alerting, Utility, etc.

77.
探讨#1：需求变更导致新增
字段，你会怎么做？

78.
探讨#2：你身边有哪些软件，
始终坚持着“简单”？

79.
广告#1：Component Identification
via DDD (王概凯, Kevin)

80.
广告#2：Domain-Specific Language
(张雪峰, William)

81.
广告#3：领域特定语言(Martin Fowler)

82.
Q & A