N-layer design & development
Download as PPTX, PDF13 likes2,130 views
本文件讨论了n层架构与MVC设计的优势，强调了职责分离和代码复用的重要性。它还探讨了应对复杂性的方法，如分而治之和关注点分离，并结合了行业案例来阐述这些概念。最后，文中讨论了如何提高开发效率以及设计良好的软件系统所需的策略。
N-layer design & development
- 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 目标！
- 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)？
- 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
- 33. Demo – 解决局部外部依赖问题 #1：获取当前应用登录者 #2：模拟Repository Layer
- 34. Demo – Unit Testing Case Generator Pex
- 35. Unit Testing 是提高软件质量的源头之一， SoC 同样如此，让我们看一个案例。。。
- 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.
- 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
- 47. 问#4：Declarative vs. Imperative ? What vs. How 不局限于Cross-Cutting Domain-Specific Language (DSL)
- 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.
- 79. 广告#1：Component Identification via DDD (王概凯, Kevin)
- 80. 广告#2：Domain-Specific Language (张雪峰, William)
- 82. Q & A