DDD（一）微服务、领域驱动设计、领域模型
如果觉得样式不好：跳转即可 http://www.lifengying.site/（md文件复制过来有些样式会不一样）
什么是微服务
单体结构项目
优点：结构简单，部署简单等
缺点：耦合；技术栈统一，软件包版本锁定；一崩全崩；升级周期长；无法局部扩容；
微服务结构项目
优点：耦合性低，易于开发和维护；可以用不同技术栈；可以单独扩容；互相隔离，影响小；部署周期短；
缺点：对运维能力要求高；运行效率会降低；技术要求高，需要处理事务最终一致性等问题。
微服务的误区
微服务架构应该是进化而来的；微服务的拆分进化。（项目起步应该拆分的服务很少可能只有2 3个，慢慢的随着系统业务越来越庞大，慢慢再拆分）
在设计不好的微服务架构中，微服务之间的调用关系非常复杂，一个来自客户端的请求甚至要经过七八层的微服务调用，这样糟糕的设计不仅导致系统间耦合严重，而且使得服务器端的处理效率非常低。
在项目初始阶段，需要认真思考，我们是否非用微服务不可，并拿出充足的理由。不要为了微服务而微服务。
DDD（domain driven design）领域驱动设计
1、是一个很好的应用于微服务架构的方法论。
2、在项目的全生命周期内，所有岗位的人员都基于对业务的相同的理解来开展工作。所有人员站在用户的角度、业务的角度去思考问题，而不是站在技术的角度去思考问题。
3、诞生于2004年，兴起于2014年（微服务元年）。
例如：当我们需要开发一个电力系统的时候，我们可能需要了解电力相关的知识或者说成为一个电力专家，当我们开发一个金融系统的时候，我又要成为一个金融专家等等。成本很高。而且我们只开发系统，也不需要成为每一个领域的专家。
4、DDD晦涩难懂，难以落地。因为DDD是方法论，不是行动指南。
5、“盐少许、油少许“，每个人对DDD的理解和落地都不同，而且没有绝对的对错。
6、如果只学习DDD概念而没有了解如何应用的话，会感觉没有落地；而如果过早关注落地的话，会导致理解片面。
7、正确姿势：“从理论到实践，从实践再到理论……” 我的讲课顺序：把概念的讲解和技术落地分开。Why？
8、不要一下子学DDD的整体。不同岗位、不同阶段的人先从自己的角度学习DDD的一部分。
领域
1、“领域”（Domain）：一个组织做的事情。子领域。
2、领域的划分（以手机公司为例）：
核心域：解决项目的核心问题，和组织业务紧密相关。
支撑域：解决项目的非核心问题，则具有组织特性，但不具有通用性。
通用域：解决通用问题，没有组织特性。
3、领域的不同分类决定了公司的研发重点。
领域主要指一个组织做的所有的事情，但是一般为了缩小讨论的范围，会划分为多个子领域。
例如：手机公司
手机研发子领域、手机制造子领域解决了手机的核心问题。
销售子领域、财务子领域、售后子领域这些都和手机相关，比如销售手机和销售电脑、销售房子需要掌握的业务知识不一样。属于支撑域。
保洁、保安统称后勤子领域、人事子领域这些领域属于通用域，手机研发公司的后勤和电子厂的后勤做的事情都是一样的。一般这种领域可以外包给第三方。
不同的组织也会导致划分的结果不一样，这里我们就用不同的公司来代替
比如上述说的外包第三方公司，但是对于保洁家政等公司来说，保洁、保安子领域又属于核心域。
总结
手机研发子领域、手机制造子领域为核心域
销售子领域财务子领域、售后子领域为支撑域
保洁、保安统称后勤子领域、人事子领域为通用域
书中销售子领域划分为核心域，但是视频里面没有明确讲销售子领域划分，我个人认为销售子领域为支撑域，如果从利润角度来划分，它又不得不为核心域，毕竟手机造出来卖不出去，没有收入，一切都是空谈
总之，同样的领域由于划分的不同结果也不一样。根据自己的公司来具体划分。
领域模型（Domain Model）
1、对于领域内的对象进行建模，从而抽象出来模型。
2、以银行为例。
银行的柜台业务领域中，就有储户、柜员、账户等领域模型。建模是DDD中非常核心的事情，一旦定义出了领域模型，我们就可以用领域模型驱动项目的开发。
3、我们的项目应该开始于创建领域模型，而不是考虑如何设计数据库和编写代码。使用领域模型，我们可以一直用业务语言去描述和构建系统，而不是使用技术人员的语言。
事务脚本
使用技术人员的语言去描述和实现业务事务。没有太多设计，没有考虑可扩展性、可维护性，流水账地编写代码。
例子：
总结：这样的代码
优点：编写简单，自然，非常符合开发人员的思维方式。
缺点：事务脚本中，本该属于支撑域的权限的概念出现了在核心域的代码中，我们应该通过AOP（aspect-oriented-programming,面向切面编程）等方式把权限校验的代码放到单独的权限校验支撑域中。这段代码的另外一个问题是，对于需求的快速变化的响应是非常糟糕的，比如系统的需要增加一个“取款金额大于5万的需要主管审批”的功能，我们可能需要对代码进行增加一个if判断，，或者系统增加一个取款成功之后短信的通知等等，随着系统的业务膨胀，上述Withdraw方法会增长到成千上万行，代码的可维护性、可扩展性非常差
DDD通用语言、界限上下文
1、“我想要商品可以被删除”→“我想要把删除的还原回来”→“Windows回收站都能”
2、此“用户”非彼“用户”。
3、通用语言：一个拥有确切含义的、没有二义性的语言。
4、通用语言离不开特定的语义环境，只有确定了通用语言所在的边界，才能没有歧义的描述一个业务对象。
为什么使用DDD(领域模式):https://juejin.cn/post/6895096192980484103
领域驱动设计(DDD)在爱奇艺打赏业务的实践:https://juejin.cn/post/7050738599649607694
CQRS Journey：https://docs.microsoft.com/en-us/previous-versions/msp-n-p/jj554200(v=pandp.10)
DSL 领域特定语言 ：以上相关博客或者书籍有时间可以自己了解和查阅。
DDD之实体、值对象
实体（Entity）
1、“标识符”用来唯一定位一个对象，在数据库中我们一般用表的主键来实现“标识符”。主键和标识符的思考角度不同。
2、实体：拥有唯一的标识符，标识符的值不会改变，而对象的其他状态则会经历各种变化。标识符用来跟踪对象状态变化，一个实体的对象无论怎样变化，我们都能通过标识符定位这个对象。
3、实体一般的表现形式就是EF Core中的实体类。
值对象（Value Object）
1、值对象：没有标识符的对象，也有多个属性，依附于某个实体对象而存在。比如“商家”的地理位置、衣服的RGB颜色。
2、定义为值对象和普通属性的区别：体现整体关系
总结：
核心是看是否能自己独立存在
能就是实体，否就是值对象
例如
身份证ID不会变 但是年龄、姓名、居住地址、有效期等等都会变化，由于身份证ID没有变，这个人（对象）还是之前的那个人（对象）。
反过来就算年龄、姓名、居住地址、有效期等等都一样，但是身份证号不一样，那也是2个不同的人（对象）
本文内容大部分都为杨中科老师《ASP.NET Core技术内幕与项目实战》一书中内容，此文只是做学习记录，如有侵权，联系立马删除。
标签：服务,对象,领域,手机,驱动,标识符,DDD 来源： https://www.cnblogs.com/firstsaofan/p/16584589.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。