领域驱动的实践与思考
领域驱动的实践与思考
目的：
- 提高代码质量，让系统更健壮，让服务微起来，形成领域建模思维。
问题：
什么是高内聚，低耦合
内聚：相同的放在一起
耦合：耦合（Coupling）表示两个子系统（或类）之间的关联程度，当一个子系统（或类）发生变化时对另一个子系统（或类）的影响很小，则称它们是松散耦合的；反之，如果变化的影响很大时，则称它们是紧密耦合的。耦合的强弱取决于模块间接口的复杂性、引用模块的位置和数据的传送方式等。设计时应尽量使模块问的耦合度小，模块间的耦合度直接影响系统的可理解性、可测试性、可靠性和可维护性。
<u>出现边界问题</u>
做项目还是做产品：要做产品，不要做项目
项目：一般具有针对性，项目越做越臃肿。
产品：一般产品具有通用性，抽象出来的一种功能组合。强调用户的体验。产品一般是越做越好，很注重质量，其准则是开发出比其他同类产品更好用，更快的系统。
做产品对人员的要求：精兵强将，好的开发者、好的测试、
数据驱动设计、页面驱动设计？微服务，都不要，要DDD
做微服务：领域驱动设计
微服务 >> DDD
事件：（输出）
一个需求，一个功能，我们关注的是最后出来的东西？
事件：
领域专家关心的，在业务上真实发生的事。如：支付订单已提交；对账已完成，每天凌晨触发 事件风暴： 领域专家和技术专家共聚一堂，能够数小时内理解复杂领域，简单（无需建模（UML）），与DDD是高度匹配的。 领域事件： 是领域重要的，能够引起其他对象发生响应的事件。事件通常通过数据来描述。 识别事件： 确定要进行的、单一且清晰的事件风暴的业务场景（参与者可随时提问） 记录每一个参与者自己理解的领域事件，（同步发生的事件竖排放在一起）（一般用橙色便利贴，格式为xxx已xxx ，如：支付订单已提交） 事件根据时间顺序排序 发现问题点，记录为什么是一个问题，（一般用红色便利贴） 完成以上步骤，从最后一个事件开始反向验证事件的完整性，主要是为了走查前后事件的关联关系，防止事件被遗漏 为什么用事件： 是一种领域建模的实践，是一种快速探索复杂业务领域的方法 通过事件的方式对过去发生的事情进行溯源， 因为过去所发生的对业务有意义的信息都会通过某种形式保存下来。 事件风暴能够让领域专家和工作坊参与者一起明确在业务上究竟是什么领域模型发生了什么改变， 最终的软件系统需要关注业务过程中发生的业务数据的变化。
命令：输入
什么活动产生了事件（提交支付订单，启动定时任务对账） 为什么用命令： 事件是业务上的输出，命令是业务上的输入， 命令以及相应角色可以明确最终软件系统会有哪些功能给外界使用， 命令和事件将会指导API的设计。 识别命令： 命令会产生事件，将命令写在事件左边（一般是蓝色便利贴） 命令可能会产生多个事件，一个事件也可能由多个命名产生 命令可以是：用户从UI界面进行的操作、外部系统的触发、定时任务 最终识别出角色（是系统、是个人等）
聚合：（业务名词）
聚合 聚合是一组相关领域模型的集合 是用来封装业务的不变性， 确保关联关系紧密的领域模型能够内聚在一起
为什么用聚合 使用聚合的目的是封装业务的不变性 只能通过聚合根修改边界内的对象 聚合根有全局标识 同时强迫大家尽可能的简化领域模型之间的关联关系 在业务层面进行高内聚，低耦合的设计 识别聚合： 按照事件顺序依次通过提问来分析： 这个事件会改变领域对象模型什么？明确领域模型（事件中涉及的业务名词） 这个领域是否可以独立访问？是就是聚合 如果不能独立访问应该需要通过哪些 领域模型来访问？当前领域模型就是与该可独立访问的领域模型视为同一个聚合 将命令贴在聚合的左面，是聚合的输入，事件贴在聚合的右面，是聚合的输出。 再根据聚合的原则来检验上面的划分结果是否匹配，如果不匹配则基于划分原则并结合业务重新调整聚合。
边界：
什么是限界上下文？ 限界上下文可以分为限界和上下两个词来理解； 限界：指一个界限，具体的某一个范围 上下文：场景、环境；所以限界上下文是在某个场景或环境下的业务边界。该边界就是业务上的职责。 为什么使用限界上下文？ 业务的扩展会产生越来越多的领域模型，任何大型项目都会存在很多的领域模型， 当不同领域模型对应的软件代码被放在一起后，软件就变的庞大且复杂， 代码难于理解、且容易出现Bug,所以需要通过限界上下文来明确定义领域模型的范围职责。 如何划分限界上下文？ 基于前面输出的聚合和领域模型，判断这些领域模型要解决的业务问题，这些问题是否为同一个问题，如果是同一个问题，则放到一个限界上下文中（一个问题对应一个限界上下文），如果不是，则拆分到不同的限界上下文中， 上面环节中所定义的问题大小（需要考虑问题的变化原因、内在逻辑等），需与领域专家共同讨论完成。 限界上下文的划分依据？ 围绕语言边界 与业务能力保持一致 围绕团队创建上下文 业务边界：识别业务主题，利用语义相关性和功能相关性对用例归类，单一抽象层次原则+正交原则 工作边界：限界上下文允许并行开发的程度 应用边界：从技术角度考虑和变化的应对，遗留系统的集成。
限界上下文明确地定义模型所应用的上下文，每一个限界上下文都是在明确边界。
场景分析领域建模
如何完成一个复杂的业务
数据流向
流向架构
实例：运单支付场景
没有最好的架构，只有更好、更合适的架构，随着你对业务领域的理解加深，你会发现重构是永无止境的。
以上是 领域驱动的实践与思考 的全部内容， 来源链接： utcz.com/z/518278.html
