本文主要是介绍DDD ,人都学习了,你还不赶紧抓紧学,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
好记忆不如烂笔头,能记下点东西,就记下点,有时间拿出来看看,也会发觉不一样的感受。
以下全是干货总结,实战代码不在此列,可关注微信公众号,留言获取相关资料。
目录
一、DDD概念
二、方法论
三、技术架构
四、使用启发
五、总结
一、DDD概念
1、是一种方法论,不是一种架构,是对软件所涉及到的领域进行建模,以应对系统规模过大时引起的软件复杂性的问题;
2、且对微服务系统的拆分以及项目的重构有章可循,避免依赖项目成员无章可循的经验进行拆分与设计;
3、是一种可以借鉴的思想,而非严格遵循的方法论。根据张逸老师和欧创新老师不同方式的领域建模可证实这一点。
二、方法论
一、张逸老师给出以下过程指导用于指导DDD方法论的落地,相比欧创新老师基于事件风暴的领域建模过程更易理解,事件风暴在识别领域对象过程有些含糊不易理解。
二、在实际项目中业务服务识别及撰写、统一语言需要业务人员更加紧密的合作,同时开发人员更易理解业务领域知识,为后续工作带来持久效益。
三、张逸老师给出可以落地的过程指导:
1、根据业务需求识别业务服务规约;
2、根据业务服务的服务名,按照知识语境与亲密度识别限界上下文;
3、识别业务活动描述中的名词、动词进行归纳抽象获得领域分析建模,得到领域对象;
4、根据UML类图的关系识别聚合;
5、根据业务服务的基本流程和验收标准分解任务到原子任务(可落地的映射关系:业务服务对应远程服务、应用服务编排业务流、领域服务组合服务、聚合承载原子服务操作)。
三、技术架构
1、不管是张逸老师的菱形架构还是欧创新老师的四层架构,都是基于分层架构进行设计。每一层只允许与直接位于其下方的层发生耦合。降低系统的复杂度,同时满足单一职责、高内聚、低耦合、提高可复用性;
2、在微服务的演进中,随着BC能力的填充以及对性能要求,将BC直接可以拆分成新的微服务系统;
3、菱形架构和四层架构也有自己的弊端,使得业务流经过更多的层级,相比传统MVC架构性能稍微有所消耗。
四、使用启发
1、首要解决通用语言问题,统一域语言。没有基于通用语言建立的所谓的聚合,实体,值对象,只是技术层面的一种设计方式;
2、领域模型会对查询带来一定的复杂性,可以通采用CQRS来分离Query和Command;当前项目关联字段较少通过冗余或者内存关联查询解决当前复杂性;
3、张逸老师的菱形架构相比欧创新老师的四层架构更加清晰,以及对仓储层的精简减少了DO到PO的互相转换,强调了富领域模型的优势。项目中要遵守各层的功能,不能写着写着又成了贫血模型的mvc架构。
4、可能DDD的技术实现上看起来很复杂,但实际这种开发方式是从业务的角度去分析问题,指引开发者去解决问题而存在的。
五、总结
1、不同实践者在多年实践中总结了自己的一套打法,降低了学习曲线。总的的可落地过程指导与分层架构略有差异,因此DDD没有最佳实践,不能只靠阅读就能充分理解,需要通过真正的实战并结合企业与项目团队实际情况,具体问题具体分析,不要硬套概念,提炼出适合自己的应用架构才是最好的;
2、DDD改变开发人员对业务领域的思考方式,要求开发者花费更多的时间和精力来思考业务领域、研究概念和术语。实现开发者对业务有了更准确的定义和理解,减少开发后期开发与业务的沟通成本。当然对于开发者的沟通能力要求有所要求。
3、技术活动往往需要综合运用多种知识,培训涉及到的周边支撑知识需要在业余时间进行查漏补缺;
更多精彩,请关注:码出精彩(codingba),我们一起学习探讨!
这篇关于DDD ,人都学习了,你还不赶紧抓紧学的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!