Marzlam的博客

DP ： Domain Primitive 可以理解为 原生业务模型 是一个在特定领域里，拥有精准定义的、可自我验证的、拥有行为的值对象 三个原则： 让隐性的概念显性化 让隐性的上下文显性化 封装多对象行为 可维护性：调整内容修改的难易度 依赖程度（看别人脸色） 自己办事 省事 可扩展性：新增方法的难易度 继承程度 省事 可测试性：测试的困难度 封装抽象程度 多个重复实列-抽象 省事 可阅读性：代码的清晰度 循迹程度 一眼就明白 省事 DO： Data Object 数据库对应模型

在进行代码 项目的构建开始之前：应该将 业务的 领域（业务）=聚合 实体 值对象 领域服务/行为 领域事件整理清楚 然后还有4种模式，这决定我们写代码 这个 构造 实体的内容饱满程度 （图片从网上找的） 失血和胀血就不适用 过多过少都不行 贫血和充血 都包含了 业务领域中的 实体模型 操作说明 ...

总结上一篇DDD： 将数据为核心 处理业务 转变为 以业务为核心 产生数据 从而达到下面4个效果 通用语言 统一思想：统一项目各方业务、产品、开发对问题的认知，而不是开发和产品统一，业务又和产品统一从而产生分歧。 领域抽象 明确分工：域模型需要明确定义来解决方方面面的问题，而针对这些问题则形成了团队分钟的理解。而且抽象开来 领域模型 反映变化：需求是不断变化的，因此我们的模型也是在不断的变化的。领域模型则可以真实的反映这些变化。 可伸缩性 边界分离：领域模型与数据模型分离，用领...

DDD：就是 Domain Driven Design 领域驱动设计 这是个什么东西呢？ 简单来讲 就是 将聚焦于数据的模式 转换成 聚焦于 业务的模式 将对数据使用实现业务 转变为 一个业务领域中使用数据 各个领域都有边界 之后各个领域 交流 使用 业务通用语言沟通 为什么要用？ 以前 用单体架构 先设计数据库 完事之后 实现业务 从数据库拿数据 处理业务 是这样一个流程。 但是现在 SOA微服务架构开始火了，分布式高并发现象级业务应运而生，这个时候 就...