做湲网站,天津网站设计建设,网站自主制作平台,wordpress如何设置会员中心领域驱动是十五年前#xff0c;由Eric Evans提出的解决软件工程复杂性问题的方法#xff0c;作者从自己多年软件开发的角度出发#xff0c;通过引入领域驱动设计的概念以及一系列战略设计模式和战术方法#xff0c;为混沌的软件开发领域带来了一缕阳光。在过去的许多年由Eric Evans提出的解决软件工程复杂性问题的方法作者从自己多年软件开发的角度出发通过引入领域驱动设计的概念以及一系列战略设计模式和战术方法为混沌的软件开发领域带来了一缕阳光。　　在过去的许多年我经历了从技术岗位到管理岗位的变化也深深的意识到每一个软件的设计与实施过程之艰辛缺乏一些科学的管理方法只会让人疲于奔命毫无积累尤其是对于开发过程而言看似枯燥乏味的编码过程却充满了更大的变数。　　例如在以前传统企业开发中设计系统架构时往往会使用三层架构用户界面层业务层数据访问层上手就来但是却看似三层分立但是由于开发者开发过程中出现的一些不规范问题容易在用户界面层和数据层中堆积大量的冗余代码而中间的业务层反而非常单薄代码行很少仅仅只是实现对象的输出而已。用户界面层和数据访问层就很容易成为腐化代码随着需求的变更容易变成大泥球系统。　　尤其是那些核心模块的用户界面层代码轻易就突破了上千行甚至上万行这些代码并非完全都是由于不规范的操作造成的一定程度上也是由于个别开发者的代码不规范形成的破窗效应。不管发生了什么这些代码最终成为一座屎山。如果再加上古人写的存储过程对不起我选择自闭。　　屎山的命运往往都是一样的要么重构成功得以逆天改命要么被公司抛弃成为企业发展过程中的一座重要里程碑要么跟着公司一起成为创业者的黄粱美梦。 是什么造成了屎山是需求吗需求控制或不控制　　用户需求就像一个关在笼子里的狮子控制或不控制这是个问题。　　对于互联网公司而言一定程度上来说需求来源于产品经理的灵感乍现或来源于对竞品(被抄袭品)功能的把握不同产品经理对于产品的规划总是不尽相同以及老板和用户的反馈也是产品需求变化的原因需求的累积也会让开发者为了修改而疲于奔命而且面向互联网的产品往往比项目型软件成品面向更大的群体拥有更长的生存周期开发者为了应对需求而不节制的更改容易成为试错甚至会影响企业的生存。　　所以使用领域驱动设计方法对后端的结构进行改造甚至中台化改造成为一种非常有效的解决方案而对于面向用户的前台以及为前台而生的BFF则由于更侧重于用户数据交互而被排除于领域控制之外(即 Backend For Frontend)当然过度的依赖前端表现层也容易造成前端代码的冗余事实上前端和客户端代码也最容易成为屎山这是后话就不赘述了。　　除互联网公司需要领域驱动的方法外传统软件企业也同样需要在企业发展过程中积累的无数项目大部分项目都存在一些普遍性的共性那就是为了盲目追求实现而忽略了软件代码的健壮性和可维护性能否把功能强推下去取决于项目经理对于甲方的控制力一旦掌握优秀沟通技巧的关键岗位离职这些项目都将成为一个个不知何时会爆发的地雷。软件企业项目的复杂性有别于互联网企业的面对业务快速裂变带来的变化往往更侧重于业务层面的规模复杂一个系统的大几百个功能点如何保证质量时间成本三者的平衡这是个恒古不变的问题。　　需求让软件充满变数、而规模、质量属性也同样会影响到软件的变化要打破僵局或许领域驱动看似是一种不错的选择。看似破解之道　　然而领域驱动的实践过程却充满坎坷主要在于 Evans的原书知识密度之稠远甚于开发者热衷的技术话题。要解决某些技术问题依托互联网的资源或许能很快找到解决问题的方法但是面对领域驱动设计却让人望而生畏许多人都说虽然听说这个概念的时间不在短暂但是却总觉得没有入门。　　单纯的从概念上看引入的统一语言领域存储库实体值对象聚合根限界上下文上下文映射等名词理解上似乎很容易但是要付诸实践却并非易事。尤其还需要把这些东西引入到企业实战过程更是难上加难。领域驱动设计方法并不像那些技术书籍一般拿着书上的方法总能在自己公司找到可以实践的点。 Evans的书也好其他书也好都只是方法而不是一套行之有效马上就能使用的方案需要团队花费大量时间去应用实践。　　例如一种最常见的领域驱动架构的实践是简单四层的领域驱动分层结构在不能有效理解关注度分离的前提下架构代码同样能成为屎山而且似乎由于开发者知识传承的缺失极其容易让人难以理解和更不用说代码质量的提升只能成为倡导者实现个人价值提升的练兵场。个人想法　　我个人认为领域驱动设计方法作为一种解决复杂问题的应对之道确实值得企业对其持续关注但是否有一种能够便捷的方法让参与者能够更快的将这么好的方法论在产品研发过程中融汇贯通形成更高效的应用过程呢下面是我根据一些讨论和学习过程形成的一点思考希望能给大家带来一丝启发。　　1如何开始改变企业文化这是来自于《实例化需求》中提出的一个问题作者的原意是认为要实践TDD需要进行文化变革事实上实践DDD或许同样如此。康威定律指出一个组织拿出的技术方案设计实际上是一个组织沟通方式的体现。你的组织真的准备好开始接受这种思想的考验了吗这是个问题。　　2、确保你得到管理层的支持。这也是来自于《实例化需求》中的原话毫无疑问如果缺乏管理层的认可和支持过程变更成功的几率几乎为零。　　3、忘掉敏捷、忘掉领域驱动、忘掉概念。由于领域驱动设计方法的看似晦涩难懂容易让组织实践领域驱动的人陷入学院派或教条主义的误区这表现在组织者更倾向于使用专家给出的标准术语对领域驱动设计的方法进行解读而缺乏与企业实际相结合的形式。我个人认为为了更好的推广领域驱动设计的应用过程不应该局限于教条主义不要过分关注于概念、框架或自动化的工具而是把领域驱动设计过程解释成一种发现需求、解释需求之间的相关性、收集实例、设计测试、以及形成可自解释的开发代码的过程。　　4、从一个小项目和简单项目开始探索建立一套行之有效的方法。从一个业务结构清晰、容易细分出应用场景和业务活动的项目出发避免陷入大项目难以控制边界的过程而且大项目如果没能更好的实施只会一发不可收拾。有网友说由于项目需求的极度不确定性所以他觉得有必要引入领域驱动设计的方法来解决这个问题我个人认为这样的做法只会导致项目更加一发不可收拾尤其是在一个学习能力并不好的组织中开展领域驱动设计实践、且大家都对这套理论一知半解的前提下。　　5从产品语言中提炼统一语言。axure软件的流行让通过原型文档这种可视化需求表达成为主流。原型语言与需求的高度贴近也便于产品研发团队从中形成统一语言。　　6形成可用的产品术语表。从统一语言出发形成可以指导编程的术语表并形成对应的中英文对照表可以便捷的为开发过程提供变量命名的规则尤其是许多开发者本身的英语水平就不是特别好如果形成这样的规则或许能为代码的开发过程带来许多便利。　　7从统一语言和需求中提炼用例图。按照张逸老师的说法用例或用户故事应该满足6w特性可以尝试站在用例的角度思考这样的问题到底谁是用户需要执行这一活动的角色到底是谁为什么需要查询功能究竟要查询什么样的内容为什么需要了解分配给我的任务情况　　8从用例图和业务流程中识别限界上下文。没必要一开始就采用四色建模法采用比较简单的领域场景分析的用例分析方法进行分析同样是不错的选择例如从分析业务活动间的语义相关性也是一种值得尝试的方法。总结　　人生三境界看山是山看水是水看山不是山看水不是水看山还是山看水还是水。大概技术领域也同样如此。　　回到一个古老的问题有人问如何给一个变量命名词穷了怎么办专家的回答是按领域驱动设计的方法对变量进行命名。这就是实践领域驱动设计的大师高论已经到了看山还是山的地步。而普通开发者们总是看了几篇领域驱动设计的文章就会以为嗯我遇到的这些问题用领域驱动能解决然后就陷入一堆概念之中不可自拔。　　实践是检验真理的唯一标准唯有真的使用一个项目开始实践才能真正体会领域驱动设计的精髓。领域驱动设计思想是一种充满魅力的软件理论方法然而要把这套理论真的用起来依然需要经历一个从新手到高级新手再到胜任者、精通者和专家的学习过程。本文也同样属于一位处于新手村学习者的个人见解班门弄斧期待能抛砖引玉措辞多有不当还望海涵。　　参考资料1、Eric Evans《领域驱动设计·软件核心复杂性应对之道》　　　　　　    2、张逸 《GitChat讲座领域驱动设计实战》　　　　　　   3、Gojko Adzic《实例化需求》原文地址https://www.cnblogs.com/xiyuanMore/p/11049418.html