DDD入门笔记
最近公司新项目业务复杂，刚好推行领域驱动设计，战略设计后进行战术设计时，感觉应当做一些笔记，记一下个人的粗浅理解。
依稀记得当年白菜大部分功能完成后，我抱着它去面试，有一个面试官问我，你这个项目是不是所有的方法直接写成静态方法也能实现呢，Spring框架在你的项目里发挥了什么作用呢？
当时的我哑口无言，陷入沉思，在后来的开发中意识到Spring利用面向切面提供了全新的开发思路，事务、重试、日志、异常拦截等可以用AOP和动态代理做，可似乎到此为止了？
之前在美团的DDD应用中看到这样的说法，其实传统分层开发用的就是简化过的DDD的战术设计，缺点在于贫血症造成的失忆症，让我非常认同。
审视了一下过去半年甚至两年写的代码，DO本身没有操作只有数据，对DO操作散在各个Service，要修改一个点得寻找四五个修改点……
用Java写着过程式代码，对象被玩成了结构体，所有类托管唯一对象给Spring，唯一带点面向对象气息的Service层接口实现还是为了给动态代理提供方便，用依赖注入组合Service执行逻辑（虽然组合确实比继承要清晰）……
而DDD本来应当是面向对象的，把行为还给DO，把上帝之手Service降级成指挥官。。
接下来记一下我对一些DDD中概念的个人粗浅理解，我预感几个月或者几年后就会觉得这篇笔记的内容非常愚蠢。。
- 限界上下文（这是一个拗口的概念，英语其实是Bounded context，翻译成有界上下文可能会好听一点。。）
实际上就是指某块大范围的功能点，这块功能点内同一个名词不会有歧义，如果有歧义就需要分割成不同的上下文。
- 实体
和传统的DO类似，有独立标识，需要关注生命周期，需要持久化，比DO多了行为。
- 值对象
这是一个比较新颖的概念，在传统开发中会有一些没必要使用唯一标识的数据，但是由于使用了关系数据库，也安了一个id上去。
在领域建模时，如果能确定以后不会使用这些对象的字段进行查询或统计，就可以用值对象标识，直接序列化为字段。
之前看到的例子是订单的地址，但是订单地址也可能存在一些需要用地址字段做统计的需求，我手上有个更好的例子：报表导出的模板有数据字典列表的成员变量，每个数据字典存放了字段名和表格坐标，还可以考虑直接存放查询语句。这就是一个值对象，不会有根据字段名来统计数据字典的需求。。