Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

N-layer design & development

2,030 views

Published on

Why n-Layer, Why MVC, architecture, domain, data, soc, unit testing, cross-cutting, dev role model, 流水线作业, 术业有专攻

Published in: Software

N-layer design & development

  1. 1. n-Layer Design & Development
  2. 2. Agenda • 引子、Why n-Layer、Why MVC • Domain、Data、DDFx • HelloDDFx Demo • Q & A
  3. 3. 引子:以下哪些关于经典三层架构的描述是正确的? • 1、User Interface(UI)层一般指Web 前端,主要负责用户交互 • 2、Business Logic(BL)层一般指业务逻辑,可以包括UI 逻辑 • 3、Business Logic(BL)层一般指业务逻辑,不可以包括UI 逻辑 • 4、Data Access(DA)层一般指数据访问,主要负责关系数据库 交互 • 5、三层架构的优势是把代码分散到不同模块中,以方便程序员 编写不同的部分,实现代码重用
  4. 4. 引子:以下哪些关于经典三层架构的描述是正确的? • 1、User Interface(UI)层一般指Web 前端,主要负责用户交互 • 2、Business Logic(BL)层一般指业务逻辑,可以包括UI 逻辑 • 3、Business Logic(BL)层一般指业务逻辑,不可以包括UI 逻辑 • 4、Data Access(DA)层一般指数据访问,主要负责关系数据库 交互 • 5、三层架构的优势是把代码分散到不同模块中,以方便程序员 编写不同的部分,实现代码重用
  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. 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. 7. 携程架构设计“S”之Case Study • S  Simple & Suitable & Scalable • 以CMessaging 为例,它主要解决哪个S? • 请排序:Simple, Suitable (balance), Scalable (10x)?
  8. 8. 引子:面向对象开发三大名言 • 抽象不变,封装变化 – XXX Pattern – YYY Framework • 面向接口编程 – 低耦合 – S.O.L.I.D. 中有3 条与接口紧密相关 • 优先使用组合 – 高内聚 – Biz App 慎用继承,why?
  9. 9. Case Study:Factory + new() ?
  10. 10. Case Study:低耦合?
  11. 11. 另一低耦合案例:BLL 访问Session? SoC-style 做法:在Controller 中 访问封装过的Session Utility
  12. 12. Ctrip 2013 RCA 特点:Non-Functional Bugs
  13. 13. 开发人员的困惑:多快好省? • 多 最近项目有点多,怎么都是最高优先级? • 快 业务要求快点上,项目经理都是催命三郎 • 好 老板要求质量高,架构师说不能违背设计 • 省 加班加点人手少,copy-paste 代码最省心 • 结论:多快好省催人老,开发效率难提高
  14. 14. 10x 基础:Design + LPT + 开发效率?x 开发人员术业有专攻 开发效率大幅度提升 减少技术犯错的概率 有时间关注性能问题 有可能实现10x scalability 目标!
  15. 15. 开发效率:如何实现【术业有专攻】?
  16. 16. Why n-Layer ? Why MVC ? • 分离关注,分离依赖(SoC) – 因为分离,所以可扩展(Open-Close 原则) – 因为分离,所以可单独测试 • 传统n-Layer 或Web Forms 架构 – 分离部分关注,分离部分依赖 – UI/View 分离仍然难以解决 • MVC 架构 – 尽可能分离一切关注,尽可能分离一切依赖 – UI/View 是最难分离的-> Controller
  17. 17. 传统3-Layer & 3-Tier 的问题?
  18. 18. 传统3-Layer & 3-Tier 的问题(PetShop)?
  19. 19. 传统3-Layer & 3-Tier 的问题(PetStore)?
  20. 20. 问:传统n-Layer 两大问题?
  21. 21. 答:传统n-Layer 两大问题? #1:高耦合 跨层调用依赖实现 #2:低内聚 业务逻辑各自为政
  22. 22. n-Layer 反面案例,评估需谨慎 • Northwind – Model 诲人,SP 毁人 • Duwamish – Layer 诲人,SP、DataSet 毁人 • PetShop – Factory、POCO 诲人,【伪分层】毁人 毁人之王! • Microsoft Domain-Oriented N-Layered App – 典型Overdesign 【简单问题复杂化】之“楷模”!
  23. 23. MVC 的因果循环 让你爱上测试! • 为什么要MVC? – 实现更全面的关注点分离(SoC),简单说是职责分离! • 为什么要(更全面的)关注点分离(或职责分离)? – 更容易单元测试、接口测试、压力测试、性能测试、etc. • 为什么要(更容易的)xxx/yyy/zzz 测试? – 体现更健壮的设计理念(TDD)! • 为什么要(更健壮的)设计理念? – 创造出更高质量的软件产品! • 为什么传统n-Layer 或Web Forms 创造不出高质量软 件产品? – 不是创造不出,而是要付出很大代价(自动vs. 手工,简单vs. 复杂)! • 为什么MVC 可以创造出高质量软件产品(为什么要MVC)?
  24. 24. 问:爱上单元测试两大障碍?
  25. 25. 答:爱上单元测试两大障碍? #1:外部依赖(container, db, service, io, etc.) #2:体力运动(validation, comparison, etc.)
  26. 26. 答:单元测试两大障碍解决方案! #1:外部依赖 Mock (dll + service) #2:体力运动 Case Generator
  27. 27. 问:What is Mock ? Scenario ?
  28. 28. Mock Demo #1 – Interface Mock
  29. 29. Mock Demo #2 – Http Context
  30. 30. Mock Demo #3 – VS 2012 Fakes
  31. 31. 问#1:Mock 难以对付的场景?
  32. 32. 问#2:如何解决Mock 难以对 付的场景?
  33. 33. Demo – 解决局部外部依赖问题 #1:获取当前应用登录者 #2:模拟Repository Layer
  34. 34. Demo – Unit Testing Case Generator Pex
  35. 35. Unit Testing 是提高软件质量的源头之一, SoC 同样如此,让我们看一个案例。。。
  36. 36. SoC Case Study:战国铸剑(穿越场景)?
  37. 37. Case Study:战国铸剑vs. 现代工业 辰凌莞尔道:“这些东西不能让外人知道,任何一 个诸侯国都不能泄露,这是咱们的优势,另外,我看白 家铸剑坊内的工匠师,又有许多工匠助手、学徒,来帮 助他共同完成一件兵器,比如说宝剑,剑身需要铸造、 锤炼、打磨,剑柄需要挑选上好地拓木,然后套入剑柄 外壳,用牛皮一层层紧紧地缠上去,然后制作剑鞘等等, 一套流程下来,需要太多人在一起共同完成,而且每组 至少有一个铸剑师、工匠师,对不对?”
  38. 38. Case Study:战国铸剑vs. 现代工业 “是的呀,有什么不对的吗?”白若溪一双美眸紧 紧盯着庆忌,不知道他从其中看出了什么弊病。 辰凌轻笑着说:“因为这样一来,需要太多的工匠 师和铸剑师了,雇佣金太高,资源浪费,一个学徒最终 成为一个匠师,至少需要几年的时间,而且每个工匠师 的手法不同,打造出来的兵器一批批都不相同,很难打 造出品牌来。”
  39. 39. Case Study:战国铸剑vs. 现代工业 “我在想,把这种师傅带徒弟的生产模式,改成流 水线作业,也就是说,打铁的、铸剑的、做剑鞘的、打 磨的、淬火的、还原的、装饰的一条工艺下来,各个工 序分开,分成不同的工坊,流水线式生产。” “这样一来,学徒很快能上手,精熟自己工艺的活, 而且统一传授,统一掌握,打造出来的工艺也差不多, 以此类推,一柄剑铸造出来,由各个工坊配合,这样根 本不需要太多的铸剑师、工匠师带队了!”
  40. 40. SoC Case Study:工程师标签? #1:技术标签vs. 业务标签 #2:招聘岗位vs. 优先考虑 #3:开发团队vs. 咨询顾问
  41. 41. 回到Why n-Layer ? Why MVC ? #1:创业团队vs. 稳定团队 #2:小微作坊vs. 研发中心 #3:模块包干vs. 技能拆分
  42. 42. n-Layer 之特殊Layer:Cross-Cutting • Security – Authentication, SSO, etc. – Authorization – Validation • Service – Logging – Caching • Others – IoC – Transaction – Monitoring, Alerting, SLA, etc.
  43. 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. 44. 问#3:Cross-Cutting 演示中的 共同点?
  45. 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. 46. C# vNext?Cross-Cutting vNext?
  47. 47. 问#4:Declarative vs. Imperative ? What vs. How  不局限于Cross-Cutting  Domain-Specific Language (DSL)
  48. 48. Domain、Data、Declarative、 DDFx
  49. 49. Difference between Lib & Fx ? • 理解#1:框架与类库都可以认为是一种基础结构, 而我们编写的代码是应用代码 – 若是基础代码调用应用代码,则这种基础结构是框架, 如:.NET CLR,ASP.NET MVC – 反之,若是应用代码调用基础代码,则这种基础结构是类库, 如:.NET BCL,ASP.NET Web Controls • 理解#2:类库是类的集合,与类库相比,框架和类 库有着相似的形式,即框架也往往是类的集合 – 类库的类之间可能是相互独立的,应用开发者希望使用任何一 个类时可直接调用它 – 框架中的各个类不是孤立的,其业务逻辑将不同的类“连”在 一起,在它们之间建立协作关系
  50. 50. Difference between Lib & Fx ? • 总结#1:框架通过封装处理流程的控制逻辑,使它对 开发者透明,来简化开发工作! – 类库由现成的、供开发者用于构建应用的组件组成,但是,开发 者必须理解不同组件之间的关系,并编写处理流程代码把众多组 件组织起来 – 框架则不同,它通过预先把众多组件组织在一起的方式,封装了 处理流程的控制逻辑;因此,开发者就不用再编写控制逻辑来组 织组件之间的交互了 • 总结#2:Library 解决一个或多个问题,侧重复用; Framework 解决一类问题,接近半成品,更关注架构 • 总结#3:类库的基因是new,框架的基因的:
  51. 51. 什么是Domain? 作为软件方面的专家(架构师、开发人员)和领域专家 (客户方业务人员、需求分析人员),所有人在一起创建 领域的模型,这个模型会统一体现两个专业领域的交汇
  52. 52. 什么是Data? Data Files、Database、Data Service、etc. SQL、NoSQL、AWS RDS、SQL Azure、etc.
  53. 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. 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. 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. 56. DDD 典型案例- 网上书店
  57. 57. 面向对象三大名言之DDFx 注解 • 抽象不变,封装变化 尽可能使用Generics – XXX Pattern – YYY Framework • 面向接口编程 Cross-Layer 尽可能使用Factory – 低耦合 – S.O.L.I.D. 中有3 条与接口紧密相关 • 优先使用组合 Domain Model 组合Domain Object – 高内聚 – Biz App 慎用继承,why?
  58. 58. HelloDDFx Demo #1:工厂与泛型 IRepository<T>  LinqRepository<T>  RealRepository<T>
  59. 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. 60. 图表样例- 1:Visual Studio 生成
  61. 61. 图表样例- 2:Visual Studio 生成
  62. 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. 63. HelloDDFx Demo #2 Webforms/MVC/Ajax
  64. 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. 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. 66. Interface Case Study • 机票捆绑卖保险 – 方案#1:只提供机票方法 – 方案#2:既提供机票方法,也提供保险方法 • 酒店关键字搜索 – 方案#1:在现有查询方法上提供关键字查询功能 – 方案#2:新增一个关键字查询方法,内部完成调度 – 方案#3:由调用方分别调用关键字搜索、酒店查询方法 • 简单总结: Interface Design ϸÔòÁ½Ìõ
  67. 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. 68. Ctrip DDD Real Projects • 度假供应商管理– 周啸洪、李少鹏 • 公共服务积分商城– 李小林、顾新春 • More complex business projects ? • All complex business projects ?
  69. 69. HelloDDFx Demo #3 WP/Android
  70. 70. HelloDDFx Demo #4 Declarative-Driven Development
  71. 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. 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. 73. 回到10x 基础:Design + LPT + 开发效率?x 开发人员术业有专攻 开发效率大幅度提升 减少技术犯错的概率 有时间关注性能问题 有可能实现10x scalability 目标!
  74. 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. 75. 现状:熟悉某几个模块vs. 精通所有技术 建议:熟悉全组业务vs. 精通某几门技术
  76. 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. 77. 探讨#1:需求变更导致新增 字段,你会怎么做?
  78. 78. 探讨#2:你身边有哪些软件, 始终坚持着“简单”?
  79. 79. 广告#1:Component Identification via DDD (王概凯, Kevin)
  80. 80. 广告#2:Domain-Specific Language (张雪峰, William)
  81. 81. 广告#3:领域特定语言(Martin Fowler)
  82. 82. Q & A

×