不再惧怕改需求DDD领域驱动设计
如果你对自己要开发的业务领域没有清晰的定义和边界，没有设计系统的领域模型，而仅仅跟着所谓的需求不断开发功能，一旦需求来自多个方面，就可能发生需求冲突，或者随着时间的推移，前后功能也会发生冲突，这时你越是试图弥补这些冲突，就越是陷入更大的冲突之中。
开发的两种模式:1事物脚本模式,2 领域模型模式
事务脚本模型
事物脚本模型是贫血模型,模型里面没有业务逻辑,只有数据,
代码调用传递的参数一般只是数值,不是带有方法的对象
业务逻辑放在service里面.
有新的产品种类,就要新建一个service或者修改service增加if判断.
领域模型
领域模型才是真正的面向对象
领域模型是合并了行为和数据的领域的对象模型。
通过领域模型对象的交互完成业务逻辑的实现，也就是说，设计好了领域模型对象，也就设计好了业务逻辑实现。和事务脚本被称作贫血模型相对应的，领域模型也被称为充血模型。
使用领域模型增加新的产品类型的时候，就不需要修改现有的代码，只需要扩展新的产品类和收入策略类就可以了。
不符合领域模型的需求是伪需求.
DDD 驱动设计" title="领域驱动设计">领域驱动设计
什么是领域? 淘宝网的领域是C2C电子商务,
包含很多子域,子域有 用户,商品,订单,库存等等 注意 子域并不是子系统,不是一个模块
强相关的子域组成界限上下文,一个界限上下文可以包含多个子域,
可以理解成界限上下文就是一个子系统,一个模块.
领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。
在 DDD 中，领域模型对象也被称为实体，每个实体都是唯一的，具有一个唯一标识，一个订单对象是一个实体，一个产品对象也是一个实体，订单 ID 或者产品 ID 是它们的唯一标识。实体可能会发生变化，比如订单的状态会变化，但是它们的唯一标识不会变化。
值对象,创建后不会被修改的对象,如地址对象.
值对象的一个特点是不变性，一个值对象创建以后就不能再改变了。如果地址改变了，那就是一个新地址，而一个订单实体则可能会经历创建、待支付、已支付、代发货、已发货、待签收、待评价等各种变化。
DDD 有多种架构方案
最典型的是 分层架构:
用户接口层,应用层,领域层
领域实体被放置在领域层，通过应用层对领域实体进行包装，最终提供一组访问接口，通过接口层对外开放。
还有一个知名的六边形架构
DDD的 核心
最核心的是领域模型本身
通过领域实体及其交互完成业务逻辑处理才是 DDD 的核心目标。至于是不是用了 CQRS，是不是事件驱动，有没有事件溯源，并不是 DDD 的核心。
大龄程序员的优势
优势是 : 对一个业务领域多年的积淀,对一个业务领域有深刻理解.
至于curd代码,一个新人照样能胜任,工资还少,事少.
那么如何将这些业务沉淀和理解反映到工作中，体现在代码中呢？也许可以尝试探索领域驱动设计。如果一个人有多年的领域经验，那么必然对领域模型设计有更深刻的认识，把握好领域模型在不断的需求变更中的演进，使系统维持更好的活力，并因此体现自己真正的价值。
好的程序员的工作效率是一般程序员的10倍甚至更多。好的程序员不仅代码写的漂亮，可维护性强 ，面对需求变动时能更从容面对。那如何做一个好的程序员 我想对领域的理解，对需求的理解 ，具有一定的前瞻性思考，适时提出自己的建设性建议，通过代码让公司的业务系统可持续发展，推动公司业务的增长。
总结
事务脚本模式的特点在于状态都在数据库里，业务逻辑在service层，业务逻辑与状态完全分离。
领域对象模型，特点是聚合状态和操作，提供相对独立的模块和类。领域的模型的对象之一是实体，有唯一标识，实体被销毁前标识不变，能通过标识获得，实体的状态会变化。领域的另外一种对象是值对象，状态在生命周期内不变，因而更简单。领域对象因为有状态可以表达更为丰富的关系。但是设计好的领域对象依靠的主要不是技术而是对业务的理解。
本文大部分摘抄自李智慧的 领域驱动设计：35岁的程序员应该写什么样的代码？
以上是 不再惧怕改需求DDD领域驱动设计 的全部内容， 来源链接： utcz.com/z/515556.html
