【DDD】——带你领略领域驱动设计的独特魅力
🎼个人主页：【Y小夜】
😎作者简介：一位双非学校的大三学生，编程爱好者，
专注于基础和实战分享，欢迎私信咨询！
🎆入门专栏：🎇【MySQL，Javaweb，Rust，python】
🎈热门专栏：🎊【Springboot，Redis，Springsecurity，Docker，AI】
感谢您的点赞、关注、评论、收藏、是对我最大的认可和支持！❤️
目录
🎈理解DDD设计思想及核心四层架构模型
🎋概念
🎋以领域划分为基础
🎋以四层架构为工具
🎋有助于解决系统老化问题
🎈DDD如何应对软件核心复杂性
🎋技术主动理解业务
🎋“刚刚好”解决问题
🎋DDD和设计模式有什么区别
🎈DDD改造实例
🎈缺点
🎈理解DDD设计思想及核心四层架构模型
误区：认为DDD的四层架构就是DDD的整体
🎋概念
2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design
–Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。
DDD是一种设计思想，通过事件风暴使用通用语言对业务进行领域建模，通过限界上下文进行合理的领域拆分，可以使得领域模型转向微服务的设计和落地，从而解决复杂软件难以理解，难以演进，也可以解决微服务业务界限难以界定的问题。
🎋以领域划分为基础
领域的核心是边界（领域之间既有合作又有边界）
🎋以四层架构为工具
架构风格核心为：依赖
🎋有助于解决系统老化问题
当然，微服务其实也可以解决系统老化的问题
但是其实ddd看问题的角度是变化，在变化过程中，微服务体现出的问题治标不治本
软件核心的复杂性，并不是来源于庞大的软件体量或者负责的业务流程，而是来源于项目长期迭代过程中不断冒出的超出当初设计支出的不确定性。
🎈DDD如何应对软件核心复杂性
🎋技术主动理解业务
主动放下技术身段，去贴切理解业务。
🎋“刚刚好”解决问题
我们大多数很多时候，我们会做一些提前设计。 但实际上，很多时候业务不是按技术而去发展的。DDD强调由技术人员出面，主动从技术角度思考问题，我们的每一步设计，就只需要解决到当前的问题就好了，哪些不确定的问题，我们只需要保留一定的可扩展度，留在日后再去解决。
🎋DDD和设计模式有什么区别
1.DDD强调团队合作，团队内的技术人员与业务人员用同样的方式思考问题。
软件有没有问题，业务说的算，而不是架构师说的算。
2.DDD强调“刚刚好”处理眼前的需求，避免过度设计。
好用的自行车比看不懂的宇宙飞船更有价值。
🎈DDD改造实例
DDD小妙招
1.使用充血模型的实体对象，描述核心业务。（系统做什么事情，一目了然）
例如：
我们传统使用的POJO只承载数据，不包含业务（贫血模式）
实体充血模型：将实体的属性以及引起实体状态变化的方法写到实体中。
2.使用仓库和工厂，封装实体持久化操作（摆脱数据库限制）
3.构建防腐层，隔离外部服务（众人皆醉我独醒）
4.使用领域服务，封装夸实体业务（保持实体纯粹性，出淤泥而不染）
🎈缺点
DDD并不是万能的银弹，映射到具体的业务场景时，DDD的理论体系也是需要由模糊到清的。
战略层次：
- DDD缺乏一个规范的指导过程。
- DDD没有万能的需求管理体系
- DDD并没有给出明确的领域建模方法
- 对团队整体的技术能力要求高
- DDD学习成本高
技术层面：
- 直接指导DDD落地的框架非常少
- DDD是动态发展的，在不同的技术环境下，表现不同的表现形式。