关于领域驱动架构DDD思考

一个高大上的概念领域驱动架构就这样展开。

开发了多年的软件，一直以来的习惯是拿到产品的需求 对照UI的图纸然后就干干干 碰到问题大不了找人沟通再次定义问题，最后交付。其实最后也能把一件事情完成 但如果碰到很大型的项目，面对里面的各个模块 你会感觉无从下手，甚至都无法创造，理不清种种，有冲动想画画在纸上 又无从下手。

如果一开始能从更高层面的角度去设计系统 一步一步 那之后的事情 其实只是填充代码了，其实这种能力往往比编码更重要。

涉及到几个概念：心智建模 数据建模

心智建模一般还停留在会议层次上，做一个产品  一开始产品 开发一起讨论这个新产品1期功能有哪些 开完会后大家有一个初步印象 1.0我们到底需要完成哪些功能 时间节点是什么

之后数据模型就显现了我们开始关心把它实际化。

DDD模型：

UI层

应用层

领域层

基建层

UI层和基建层不难理解 一个负责展示一个负责存储

应用层和领域层的区分

领域层负责实体对应的增删改查，比如订单库存的扣减，商品的下架等

应用层涉及粒度比较粗 比如下单，购物车 商品  支付等

按照DDD定义 领域模型应该捕获“业务规则”或“领域逻辑”

应用层应该捕获“应用逻辑”

领域模型

1）显性的专业知识：下单扣除库存，买东西要付款等

2）提纯 通用的规则，期间突出一个”合规“概念；下单成功的单子不可能商品被删除或库存是0等等...

最后领域模型以”界面“（接口实现）

参考https://www.zhihu.com/question/25089273