ddd

领域 ：指一个具体的应用范围，比如电商、订票管理、会议管理等，实现某一领域的功能，与其对应的商业领域一致。譬如Contoso会议管理系统从两个方面来阐述（1）系统概览：销售会议座位、创建新会议【领域的活动是什么，核心内容】（2）非功能性需求：扩展性、灵活性【降低维护成本，延长生命周期】。 有界上下文 ：引入本概念的目的是为大型、复杂系统的分解提供一种容易管理的方法。在这种分解方式下，一个大型系统由多个有界上下文构成，每个有界上下文所包含的是一个自包容的领域模型，且有自己本身的普适语言。可以将有界上下文看做是一个有着清晰一致性边界的自动化的商业组件。在通常情况下，一个有界上下文更另一个有界上下文进行通信的方法是发送事件。 上下文线路图 ：描述不同模型之间的接触点，明确说明所有需要进行翻译的通信链接，并注明任何共享模块或对象。用户在进行这些活动后得出的结果就是一种“上下文线路图”。这种地图提供的是整个系统的概览，帮忙人民理解不同的有界上下文是如何相互交互的。 失血模型 ：模型仅仅包含数据的定义和getter/setter方法，业务逻辑和应用逻辑都放到服务层中。这种类在java中叫POJO，在.NET中叫POCO。 贫血模型 ：贫血模型中包含了一些业务逻辑，但 不包含依赖持久层的业务逻辑 。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出，贫血模型中的领域对象是不依赖于持久层的。

前有幸拜读过诸多大神关于DDD的实现落地等文章，学习较多，受益匪浅，在此推荐 : https://www.cnblogs.com/hafiz/p/9388334.html https://blog.csdn.net/k6T9Q8XKs6iIkZPPIFq/article/details/78909897 https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html https://blog.csdn.net/bluishglc/article/details/6681253 下面参考了DDD官方的结构，总结了前辈们的相关经验，再根据自身对微服务和DDD学习和理解，做了一个用SpringCloud搭建的最基本的结构例子。个人才疏学浅，如有雷同或是不当之处，望各位大佬见谅和帮忙指正。 首先引经据典 , 参考官方架构草图，DDD总体结构分为四层 : Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces(表示层，也叫用户界面层或是接口层)，各个层面的作用下面介绍。 　　　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　 对于DDD的设计而言，最重要的是如何去划分领域，划分好边界。在代码设计上，之前有看到过大佬用模块

2020年春节第一天，早早醒来，出去晨跑一下，目前武汉以及周边的疫情处于红色报警状态，今年春节宅家是最安全的做法。闲暇之余，还需要探索技术，跑步中忽然想到了【忒修斯之船】的小故事，感觉很值得玩味，也可以结合程序再次重温一下，DDD 系列之【实体建模】的一些皮毛见解。 所谓的【忒修斯之船】亦称为忒修斯悖论，是一种有关身份更替的悖论。假定某物体的构成要素被置换后，但它依旧是原来的物体吗？公元1世纪的时候普鲁塔克提出一个问题：如果忒修斯的船上的木头被逐渐替换，直到所有的木头都不是原来的木头，那这艘船还是原来的那艘船吗？因此这类问题现在被称作“忒修斯之船”的问题。其实本质就是 一个物体 整体与局部之间的辩证法，一般而言，系统的整体大于局部。 一般而言，我们认为无论【忒修斯】的【船】被替换过多少的零件（木头），船还是那艘船，不会因为木头的替换就有所改变。那么如果被替换的零件都得到很好的保存，而且用替换的零件也组装了一条与【忒修斯之船】一样的船。姑且认为是【旧忒修斯之船】，这个时候，出现了问题的：到底那艘船才是真正的【忒修斯之船】呢？【忒修斯】不可能同时拥有两艘一样的船啊！ 涉及到我们今天要谈到的话题，DDD领域下众多环节中的【实体】建模，受启发于上面的哲学小故事，当我们尝试采用【实体】模式对某一业务进行的时候，需要为该【实体】确立唯一的标识，保证未来的一段时间内

最近发现文章老是被窃取，有些平台举报了还没有用。请识别我的id 方丈的寺院 。 摘要 DDD领域驱动设计，起源于2004年著名建模专家Eric Evans发表的他最具影响力的著名书籍：Domain-Driven Design –Tackling Complexity in the Heart of Software（中文译名：领域驱动设计,之后进行了很多迭代和演化，不过大多没有脱离这本书讨论的范围。因为Eric Evans在该书中只是提供了一套原始理论，并没有提供一套方法论，更别说可落地。所以十几年，对于DDD争论不休，毁誉参半，喜欢的人觉得他解决了软件设计的复杂性，不喜欢的人觉得他使得代码设计更加复杂了。 关于DDD的理论讨论，案例分析的博客也浩如烟海，但是关于他应该如何被引进团队，一步步实施下去，却很少见，导致很多人想从0开始的人，不知道如何开始。所以我在写DDD系列开始前，先写一下DDD是如何在我们团队落地，希望能够对你有所启发。 DDD落地为什么这么难 敏捷迭代，放弃建模 现代互联网产研团队的构成一般是市场/运营、产品、UI交互、前端、后端、测试。这些角色的分工是将一个产品开发上线的各个过程拆分出来，然后每个过程专人负责，可以有效提高生产效率，这一套流程是标准的 流水线作业 。这样做的好处毋庸置疑，坏处也很明显，每个人只盯着自己那一块，而 忽略整体 了。 再来看DDD

本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/gk-Hb84Dt7JqBRVkMqM7Eg 作者：张文博 领域驱动设计（Domain Driven Design，DDD）其实并非新理论，大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年，距今已十余年时间。与现在的分布式、微服务相比，绝对是即将步入中年的“老家伙”了。 直到近些年微服务理论被提出、被互联网行业广泛使用，人们似乎又重新发现了领域驱动设计的价值。所以看起来也确实是因为微服务，领域驱动设计才迎来了第二春。 不过我发现大家对DDD也存有一些误区，使其渐渐成了一门“高深的玄学”，随之又被大家束之高阁。我本人在过去两年多的时间里，研读过多本DDD相关的经典论著、也请教过一些资深DDDer，并在项目中实践过。 不过在初步学习、实践之后我又带着疑问与自己的思考重新读了一遍相关的著述理论。逐渐领悟到DDD作为一种思想，其实离我们很近。 我把自己的学习过程、思考编写成系列文章，与大家一起探讨学习，希望大家能够有所收获，当然其中不正确的地方也欢迎大家批评指正。 同时，在文章中我也会引用相关的论著或者一些我认为不错的案例素材，权当是我们对这些知识的详细诠释，在这里一并对这些DDD前辈的不倦探索表示感谢。 （DDD相关的经典论著） 一、关于DDD的误区

本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/gk-Hb84Dt7JqBRVkMqM7Eg 作者：张文博 领域驱动设计（Domain Driven Design，DDD）其实并非新理论，大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年，距今已十余年时间。与现在的分布式、微服务相比，绝对是即将步入中年的“老家伙”了。 直到近些年微服务理论被提出、被互联网行业广泛使用，人们似乎又重新发现了领域驱动设计的价值。所以看起来也确实是因为微服务，领域驱动设计才迎来了第二春。 不过我发现大家对DDD也存有一些误区，使其渐渐成了一门“高深的玄学”，随之又被大家束之高阁。我本人在过去两年多的时间里，研读过多本DDD相关的经典论著、也请教过一些资深DDDer，并在项目中实践过。 不过在初步学习、实践之后我又带着疑问与自己的思考重新读了一遍相关的著述理论。逐渐领悟到DDD作为一种思想，其实离我们很近。 我把自己的学习过程、思考编写成系列文章，与大家一起探讨学习，希望大家能够有所收获，当然其中不正确的地方也欢迎大家批评指正。 同时，在文章中我也会引用相关的论著或者一些我认为不错的案例素材，权当是我们对这些知识的详细诠释，在这里一并对这些DDD前辈的不倦探索表示感谢。 （DDD相关的经典论著） 一、关于DDD的误区

/* <p> <span> <a>xx集团</a> <span/> <b> | </b> <span> <a>xx公司</a> <span/> <b> | </b> </p> */ p{ margin-bottom: 8px; line-height: 27px; border-bottom: 1px solid #ddd; } a{ white-space: nowrap; color: #f00; text-decoration: none; } span{ margin: 0 4px; } b{ margin: 0 3px; font-weight: 400; color: #ddd; } */ 来源： CSDN 作者： 花名、未闻 链接： https://blog.csdn.net/lmq13097277321/article/details/104356502

配置文件services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new OpenApiInfo { Version = "v0.1.0",//版本号 Title = "尹大师框架说明,QQ:1390788386",//文档标题 Description = "框架说明文档",//文档描述 Contact = new OpenApiContact { Name = "道法自然", Email = "1390788386@qq.com"}//联系人 }); // Assign scope requirements to operations based on AuthorizeAttribute //options.OperationFilter<SecurityRequirementsOperationFilter>(); //设置swagger的xml文档 //c.DocInclusionPredicate((docName, description) => true); //// Define the BearerAuth scheme that's in use //c.AddSecurityDefinition("bearerAuth", new ApiKeyScheme() //{ // Description = "JWT

随着微服务的流行，项目工程往往有很多子系统组成，涉及的面也是比较广的。如何根据业务划分系统功能，限界上下文Context，非常重要，而限界上下文之间的关系有哪些呢？俯视，正视，宏观把握系统是非常重要的，掌握每个角色的作用，也非常重要。看下： 1， 合作关系（Partnership） :如果两个限界上下文的团队要么一起成功，要门一起失败，此时他们需要建立起一种合作关系。他们需要一起协调开发计划和集成管理。两个团队应该在接口的演化上进行合作以同时满足两个系统的需求。应该为相互关联的软件功能制定好计划表，这样可以确保这些功能在同一个发布中完成。 2， 共享内核（Shared Kernel） :对模型和代码的共享将产生一种紧密的依赖性，对于设计来说，这种依赖性可好可坏。我们需要为共享的部分模型指定一个显示的边界，并保持共享内核的小型化。共享内核具有特殊的状态，在没有与另一个团队协商的情况下，这种状态是不能改变的。我们应该引入一种持续集成过程来保证共享内核与通用语言的一致性。 3， 客户方-供应方开发（Customer-Supplier Development） ：当两个团队处于一种上游-下游关系时，上游团队可能独立于下游团队完成开发，此时下游团队的开发可能会受到很大的影响。因此，在上游团队的计划中，我们应该顾及到下游团第的需求。 4， 尊奉者（Conformist） ：在存在上游

领域驱动设计(DDD) - HackerVirus - 博客园 https://www.cnblogs.com/Leo_wl/p/3866629.html 领域驱动架构（DDD）建模中的模型到底是什么？_领域模型,DDD_zmh458的博客-CSDN博客 https://blog.csdn.net/zmh458/article/details/96151607 面向服务和面向领域的不同 https://www.jdon.com/45994 避免滥用http状态码，如何将后端业务错误准确地传递到Restful客户端？Spring Boot和JAX-RS的RFC-7807问题详细信息 - codecentric https://www.jdon.com/53707 我在编程20年中学到的5件事 - DaedTech https://www.jdon.com/53432 为微服务构建服务网格的Istio自身却走向微服务的反面单体架构 – Christian Posta https://www.jdon.com/53703 幽默：什么是框架？营销词语背后的真实意思 - Ambrose Bierce https://www.jdon.com/53704 如何设计最佳的微服务架构 -DZone https://www.jdon.com/53706 批处理最佳实践 - Vlad Mihalcea