n-Layer Design & Development

Agenda

• 引子、 Why n-Layer 、 Why MVC

• Domain 、 Data 、 DDFx

• HelloDDFx Demo

• Q & A

引子：以下哪些关于经典三层架构的描述是正确的？

• 1 、 User Interface （ UI ）层一般指 Web 前端，主要负责用户交互

• 2 、 Business Logic （ BL ）层一般指业务逻辑，可以包括 UI 逻辑

• 3 、 Business Logic （ BL ）层一般指业务逻辑，不可以包括 UI 逻辑

• 4 、 Data Access （ DA ）层一般指数据访问，主要负责关系数据库交互

• 5 、三层架构的优势是把代码分散到不同模块中，以方便程序员编写不同的部分，实现代码重用

引子：以下哪些关于经典三层架构的描述是正确的？

• 1 、 User Interface （ UI ）层一般指 Web 前端，主要负责用户交互

• 2 、 Business Logic （ BL ）层一般指业务逻辑，可以包括 UI 逻辑

• 3 、 Business Logic （ BL ）层一般指业务逻辑，不可以包括 UI 逻辑

• 4 、 Data Access （ DA ）层一般指数据访问，主要负责关系数据库交互

• 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 已不能带来快乐，就考虑“停止”它。

引子：应对复杂问题两大策略• 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

• S Simple & Suitable & Scalable

• 以 CMessaging 为例，它主要解决哪个 S ？

• 请排序： Simple, Suitable (balance), Scalable (10x) ？

携程架构设计“ S” 之 Case Study

引子：面向对象开发三大名言• 抽象不变，封装变化– XXX Pattern– YYY Framework

• 面向接口编程– 低耦合– S.O.L.I.D. 中有 3 条与接口紧密相关

• 优先使用组合– 高内聚– Biz App 慎用继承， why ？

Case Study ： Factory + new() ?

Case Study ：低耦合 ?

另一低耦合案例： BLL 访问 Session ？

SoC-style 做法：在 Controller 中

访问封装过的 Session Utility

Ctrip 2013 RCA 特点 ： Non-Functional Bugs

• 多 最近项目有点多，怎么都是最高优先级？

• 快 业务要求快点上，项目经理都是催命三郎

• 好 老板要求质量高，架构师说不能违背设计

• 省 加班加点人手少， copy-paste 代码最省心

• 结论：多快好省催人老，开发效率难提高

开发人员的困惑：多快好省？

10x 基础： Design + LPT + 开发效率 ?x

开发人员术业有专攻 开发效率大幅度提升 减少技术犯错的概率 有时间关注性能问题

有可能实现 10x scalability 目标！

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

Why n-Layer ? Why MVC ?

• 分离关注，分离依赖（ SoC ）– 因为分离，所以可扩展（ Open-Close 原则）– 因为分离，所以可单独测试

• 传统 n-Layer 或 Web Forms 架构– 分离部分关注，分离部分依赖– UI/View 分离仍然难以解决

• MVC 架构– 尽可能分离一切关注，尽可能分离一切依赖– UI/View 是最难分离的 -> Controller

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

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

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

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

答：传统 n-Layer 两大问题？

#1 ：高耦合 跨层调用依赖实现#2 ：低内聚 业务逻辑各自为政

n-Layer 反面案例，评估需谨慎• Northwind– Model 诲人， SP 毁人

• Duwamish– Layer 诲人， SP 、 DataSet 毁人

• PetShop– Factory 、 POCO 诲人，【伪分层】毁人 毁人之王！

• Microsoft Domain-Oriented N-Layered App– 典型 Overdesign 【简单问题复杂化】之“楷模”！

MVC 的因果循环 让你爱上测试！• 为什么要 MVC ？

– 实现更全面的关注点分离（ SoC ），简单说是职责分离！

• 为什么要（更全面的）关注点分离（或职责分离）？– 更容易单元测试、接口测试、压力测试、性能测试、 etc.

• 为什么要（更容易的） xxx/yyy/zzz 测试？– 体现更健壮的设计理念（ TDD ）！

• 为什么要（更健壮的）设计理念？– 创造出更高质量的软件产品！

• 为什么传统 n-Layer 或 Web Forms 创造不出高质量软件产品？– 不是创造不出，而是要付出很大代价（自动 vs. 手工，简单 vs. 复杂）！

• 为什么 MVC 可以创造出高质量软件产品（为什么要 MVC ）？

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

答：爱上单元测试两大障碍？

#1 ：外部依赖 (container, db, service, io, etc.)

#2 ：体力运动 (validation, comparison, etc.)

答：单元测试两大障碍解决方案！

#1 ：外部依赖 Mock (dll + service)

#2 ：体力运动 Case Generator

问： What is Mock ? Scenario ?

Mock Demo #1 – Interface Mock

Mock Demo #2 – Http Context

Mock Demo #3 – VS 2012 Fakes

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

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

Demo – 解决局部外部依赖问题

#1 ：获取当前应用登录者#2 ：模拟 Repository Layer

Demo – Unit Testing Case Generator

Pex

Unit Testing 是提高软件质量的源头之一，

SoC 同样如此，让我们看一个案例。。。

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

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

Case Study ：战国铸剑 vs. 现代工业

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

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

SoC Case Study ：工程师标签？

#1 ：技术标签 vs. 业务标签#2 ：招聘岗位 vs. 优先考虑#3 ：开发团队 vs. 咨询顾问

回到 Why n-Layer ? Why MVC ?

#1 ：创业团队 vs. 稳定团队#2 ：小微作坊 vs. 研发中心#3 ：模块包干 vs. 技能拆分

n-Layer 之特殊 Layer ： Cross-Cutting

• Security– Authentication, SSO, etc.– Authorization– Validation

• Service– Logging– Caching

• Others– IoC– Transaction– Monitoring, Alerting, SLA, etc.

Cross-Cutting 有点烦，有没有好方案？• Security– Authentication, SSO, etc.– Authorization Demo #1– Validation Demo #2

• Service– Logging Demo #3– Caching

• Others– IoC– Transaction– Monitoring, Alerting, SLA, etc.

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

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

C# vNext ？ Cross-Cutting vNext ？

问 #4 ： Declarative vs. Imperative ?

What vs. How 不局限于 Cross-Cutting

Domain-Specific Language (DSL)

Domain 、 Data 、 Declarative、 DDFx

Difference between Lib & Fx ?

• 理解 #1 ：框架与类库都可以认为是一种基础结构，而我们编写的代码是应用代码– 若是基础代码调用应用代码，则这种基础结构是框架，如： .NET CLR ， ASP.NET MVC

– 反之，若是应用代码调用基础代码，则这种基础结构是类库，如： .NET BCL ， ASP.NET Web Controls

• 理解 #2 ：类库是类的集合，与类库相比，框架和类库有着相似的形式，即框架也往往是类的集合– 类库的类之间可能是相互独立的，应用开发者希望使用任何一

个类时可直接调用它– 框架中的各个类不是孤立的，其业务逻辑将不同的类“连”在

一起，在它们之间建立协作关系

Difference between Lib & Fx ?

• 总结 #1 ：框架通过封装处理流程的控制逻辑，使它对开发者透明，来简化开发工作！– 类库由现成的、供开发者用于构建应用的组件组成，但是，开发

者必须理解不同组件之间的关系，并编写处理流程代码把众多组件组织起来

– 框架则不同，它通过预先把众多组件组织在一起的方式，封装了处理流程的控制逻辑；因此，开发者就不用再编写控制逻辑来组织组件之间的交互了

• 总结 #2 ： Library 解决一个或多个问题，侧重复用；Framework 解决一类问题，接近半成品，更关注架构

• 总结 #3 ：类库的基因是 new ，框架的基因的 :

什么是 Domain ？

作为软件方面的专家（架构师、开发人员）和领域专家

（客户方业务人员、需求分析人员），所有人在一起创建

领域的模型，这个模型会统一体现两个专业领域的交汇

什么是 Data ？

Data Files 、 Database 、 Data Service 、 etc.

SQL 、 NoSQL 、 AWS RDS 、 SQL Azure 、 etc.

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 方式进行

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();– }

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

DDD 典型案例 - 网上书店

面向对象三大名言之 DDFx 注解• 抽象不变，封装变化 尽可能使用 Generics– XXX Pattern– YYY Framework

• 面向接口编程 Cross-Layer 尽可能使用 Factory– 低耦合– S.O.L.I.D. 中有 3 条与接口紧密相关

• 优先使用组合 Domain Model 组合 Domain Object– 高内聚– Biz App 慎用继承， why ？

HelloDDFx Demo #1 ：工厂与泛型

IRepository<T> LinqRepository<T> RealRepository<T>

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)

图表样例 - 1 ： Visual Studio 生成

图表样例 - 2 ： Visual Studio 生成

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.)

HelloDDFx Demo #2Webforms/MVC/Ajax

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

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 、集成测试

Interface Case Study

• 机票捆绑卖保险– 方案 #1 ：只提供机票方法– 方案 #2 ：既提供机票方法，也提供保险方法

• 酒店关键字搜索– 方案 #1 ：在现有查询方法上提供关键字查询功能– 方案 #2 ：新增一个关键字查询方法，内部完成调度– 方案 #3 ：由调用方分别调用关键字搜索、酒店查询方法

• 简单总结： Interface Design ϸÔòÁ½Ìõ

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 ？

Ctrip DDD Real Projects

• 度假供应商管理 – 周啸洪、李少鹏

• 公共服务积分商城 – 李小林、顾新春

• More complex business projects ?

• All complex business projects ?

HelloDDFx Demo #3WP/Android

HelloDDFx Demo #4Declarative-Driven Development

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.

关于应用软件开发的大胆推测 (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

回到 10x 基础： Design + LPT + 开发效率 ?x

开发人员术业有专攻 开发效率大幅度提升 减少技术犯错的概率 有时间关注性能问题

有可能实现 10x scalability 目标！

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

n-Layer Design

n-Layer Development

n-Layer Developer Role Model

UI Dev + Biz Dev + Data Dev + etc.

Interface-Oriented Design/Dev/Testing ！

现状：熟悉某几个模块 vs. 精通所有技术

建议：熟悉全组业务 vs. 精通某几门技术

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.

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

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

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

广告 #2 ： Domain-Specific Language

(张雪峰 , William)

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

Q & A