做模板网站怎么放视频,重庆招标信息网官网查询,保山手机网站建设,手机淘宝官网首页引子#xff0c;软件工程没有银弹上一篇博文领域驱动设计#xff0c;让程序员心中有码#xff0c;抛出了一个问题#xff0c;领域驱动设计真的是万能的良方吗#xff1f;对于这个问题#xff0c;大家的答案无疑是一致的#xff0c;作为一种非常受软件行业欢迎的软件思想… 　引子软件工程没有银弹　　   上一篇博文领域驱动设计让程序员心中有码抛出了一个问题领域驱动设计真的是万能的良方吗对于这个问题大家的答案无疑是一致的作为一种非常受软件行业欢迎的软件思想领域驱动设计固然有很多优点却并非万能。　　 回到十年前第一节软件工程学的课堂上我们的老师就告诉了我们一句真理软件工程没有银蛋这句话说的是软件工程领域从来没有一种思想或理论能够带来成倍的效率提升。不知不觉十年过去我们大概可以看到软件开发新技术日新月异新语言层出不穷但是无论哪种技术都不见得相对于其所对标的技术取得了成倍的提升。技术尚且如此理论就更不用说了。   领域驱动设计近年来受到技术圈的广泛追捧主要得益于微服务技术的发展。一千个读者有一千个哈姆雷特而不同的人往往对这种理论有不同的看法。如果问一个.net开发者领域驱动是什么大概他会说是abp架构。ABP架构作为完全按照领域驱动设计思想构建的技术架构目前得到了社区的广泛追捧。然而领域驱动架构和领域驱动设计依然是道和术的区别开发者在学习领域驱动架构的同时也应该了解领域驱动设计。那么领域驱动设计究竟是什么的东西由于时间和篇幅有限我无意通过代码介绍如何实现一个领域驱动的功能而是希望把领域驱动设计的基本思路进行梳理期待能通过我的梳理抛砖引玉给大家带来启迪。　　　　一领域驱动设计不错的选择　　　　作为现代软件工业发展的产物敏捷开发和极限编程实现了生产力的解放通过抛弃传统研发模式中留下的臃肿的设计文档实现了劳动生产力的提升无数互联网公司依靠灵活的开发手段为产品插上了快速开发的翅膀。开发者们不用加班分分钟就把代码撸完然后把产品质量关把好发布嗯早早的就回家休息了。然而随着产品功能的逐渐增加团队自然而然也需要扩展。可是团队成员越来越多代码质量成为一个难以把控的问题。如何保证产品功能的一致性如何保证功能符合产品的需求管理者们不厌其烦每天开会必须提开发质量必须强调变量命名注释设计原则设计模式然后每天一次集成代码审查估计已经不现实了。于是作为面子的产品质量尚且有测试把关而作为内脏的代码质量本身成为上帝的骰子好与坏全靠开发者们的自觉性和经验。　　　　冰山在软件产品华丽外表之下究竟深藏着多少问题一个复杂的数据库关系模型图 　　领域驱动设计在这样的场景下推出来的一种理念。软件系统的复杂度是开发者们没办法避免的客观情况而根据领域的实际情况建立模型是解决问题行之有效的方法。在实际过程中我们需要领域专家与开发者一起共同努力以一种特殊的方式来进行沟通并通过模型将实际生活中的问题抽象化。 　　领域驱动设计的核心是建模实际上对于大部分开发者而言建模是一个基本技能却并非每个人都能熟练的掌握。技术人员都普遍对他们工作领域有关的知识不感兴趣而更愿意从事精细的框架工作例如通过技术手段解决实际问题。而学习业务领域和领域建模的工作往往留给别人去做。然而实际上软件核心的复杂性既包括需要直接面对的技术问题而客观存在的业务问题却也是不可忽视的过份重视技术轻视建模只会导致工作重心的偏离。甚至可以说过份的重视领域驱动架构基础设施本身而忽略了建模过程在后期执行过程中可能会导致不可控制的风险。对于这一点大家都是容易理解的以前的架构简单反而容易维护而系统架构复杂了反而提高了学习成本导致不容易维护。 　　软件设计的基本原则是“高内聚低耦合”。作为一个复杂的软件工程依靠领域驱动建模将紧密联系在一起的业务设计成一个领域模型让领域模型内部隐藏细节这样让领域模型与领域模型之间的关系变得简单将极大的降低复杂业务之间千丝万缕的耦合关系。 　　　　　　　　　　　　　　　　　　　　　　　　　　面向领域设计的模型图 　　　　　　　　　　　　　二领域设计的要素统一语言和建模及文档　　 在进行设计之前我们有必要建立基本的原则那就是统一语言模型和设计文档。 　　1  统一语言 　　在日常讨论过程中我们需要跟领域专家讨论往往大家都是自己行业内的专家也意味着大家都有自己的表达问题的方式和自己的理解这有可能导致需求支离破碎。例如对对方表达的术语不了解会形成鸡同鸭讲的情况。因此需要建立一个能够互相沟通理解的语言环境例如互相的交流双方的术语并试图利用双方都能理解的词语进行问题的分析。也许在最开始这样共同语言并不能很好的运作但是却可以在后期逐渐完善。我们的开发者应该定期的了解领域所在行业的业务知识扩充自己的知识面这也有利于我们与领域专家的交流。 　　2  建模和画图 　　在我们工作过程中模型无处不在不管是在纸上绘制的简单模型或者使用专业软件绘制的各种模型都是模型。领域驱动设计本身依然依赖于模型驱动设计。学会建模对于广大开发者来说都是一项基本技能。可以说代码语言是为了与其他开发者进行沟通交流那我们建立的各种软件设计模型将极大的方便不同领域的人员进行交流。建模也可以称之为语言的一部分利用uml建立类图是一种可以比较易于接受的方式。我们可以采用以下手段来建立领域模型。 　　1)建立一个与实现绑定的模型。初版的模型也许很简陋但是它可以成为一个基础然后在后期逐渐完善。 　　2)建立一种基于模型的通用语言或表达形式和机制。通过通用语言让参与项目的所有人理解模型。 　　3)开发一个蕴含丰富知识的模型。模型不是单纯的数据结构它更是各类知识的聚合体。 　　4)提炼模型模型应该能在项目过程中动态改变发现新的概念就加进来过时的概念就适时移除避免臃肿。 　　5)头脑风暴和实验。模型在于实践和应用它需要项目参与者共同的努力而头脑风暴是发挥集体智慧的良好方式。对模型进行实验或者进行场景的模拟有利于让模型更符合需求。 　　当然对于领域专家而言不同类型的模型也许无法理解例如类图可能过于复杂可以使用画图的形式通过解释性的图形或者模型可以让不同层次的人都能获得一致的理解。 　　3  设计文档 　　设计文档依然是不可抛弃的重要资料虽然设计文档可能不利于维护却仍然不可抛弃。毕竟开发过程中通过代码和模型有可能会导致关键信息的丢失而且有的不能直接参与讨论的领域专家需要通过文档才能了解之前讨论的情况甚至可能画图会形成很多歧义这也需要解释性的文档才能说清楚。为了让文档变得更加有效不建议重复赘述已知的信息而关键信息更改后应该尽量保持最新。 完全依赖代码或架构的自解释特性目前似乎已经成为大家的普遍习惯但是代码可能存在歧义或者有的方法本身就无法表达方法的本质含义最终导致代码成为无法理解的神之领域这种问题已经不是一个单纯的领域驱动架构能够解决的。如果为了让代码来解释模型我们所有人必须时刻抱着一丝不苟严于律己的态度才能写出完全符合领域模型的代码问题是这种方式现实吗 　　4  概念总结 　　1)领域就是问题域有边界领域中有很多问题 　　2)任何一个系统要解决的那个大问题都对应一个领域 　　3)通过建立领域模型来解决领域中的核心问题模型驱动的思想 　　4)领域建模的目标针对我们在领域中所关心的问题即只针对核心关注点而不是整个领域中的所有问题 　　5)领域模型在设计时应考虑一定的抽象性、通用性以及复用价值 　　6)通过领域模型驱动代码的实现确保代码让领域模型落地代码最终能解决问题 　　7)领域模型是系统的核心是领域内的业务的直接沉淀具有非常大的业务价值 　　8)技术架构设计或数据存储等是在领域模型的外围帮助领域模型进行落地 　　　　三、问题思考　　掌握建模和基本的步骤意味着一切刚刚开始。道阻且长行则将至领域驱动设计不仅仅是一种简单的建模思想或技术架构更是一种挑战。在选择之前是否需要思考一下这一套体系真的适合在你的团队中运行么如果要切实的运行还需要付出多少代价尤其是对于领域模型而言如果缺乏合理有效、而且持续迭代的设计你难道不觉得最终所有的模型仅仅只是一种数据结构设计吗 参考资料 1.《领域驱动设计-软件核心复杂性应对之道》 2.https://blog.csdn.net/three_bird/article/details/51336834 3.https://blog.csdn.net/heweimingming/article/details/78661540原文地址: https://www.cnblogs.com/xiyuanMore/p/10085784.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com