浅谈一下关于领域驱动

现在特别流行领域驱动来设计工程，先别问领域驱动是什么？那我们现在设计系统或者项目工程用的是什么驱动？

回答是“需求驱动”，基本是产品提需求，组长做整个设计分析，两人开始合作，合作的过程中有一个问题大家有分歧，就会有点波折，所以两个人都要专业一点，按着需求一步一步完善，这样就好配合一点。

“领域驱动”，首先要理解领域，很多人做银行项目比较多，久病成医对这个领域比较擅长，算是个专家，相关领域的问题都“no problem”，但是你让他马上去设计一个境外电商系统，就可能达不到这个效果。所以说领域是一个边界，你想领域驱动，首先你要理解熟悉这个领域，知道大致都有什么业务，如何去做拆分（微服务就很考验你拆分领域的能力，你要把一个单体拆分成多个服务，所以为什么微服务突然带火了DDD领域驱动）

领域模型这个理念也是有人提出论文，大家依照思想实践出来的过程中不断完善的一个东西。

这里有一个文章不错的，比较细节：
DDD领域设计之领域模型

前面都是套话，当你问我领域模型对比别的，有什么你觉得不一样的地方？

我可能会回答是领域模型的：失血模型，贫血模型，充血模型和胀血模型

我们平常用的是什么模型？基本是贫血模型：
是指领域对象里只有get和set方法，或者包含少量的CRUD方法，所有的业务逻辑都不包含在内而是放在Business Logic层

反之充血模型：
层次结构和上面的差不多，不过大多业务逻辑和持久化放在Domain Object里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成Client->（Business Facade)->Business Logic->Domain Object->Data Access。

有一个叫做Martin Fowle的人很讨厌批判贫血的领域模型是不够优雅、不够OO的，提倡使用充血的领域模型。

这里按照他的思路来，那你的领域对象或者干脆一点，就是你的对象，不能是简单的get、set，也要参与逻辑，落到service或者logic这块就是简单的做个业务逻辑，你的DO，VO，DTO都已经整理好了。

（失血模型是比较严重的一种贫血模型，同理对应的是充血和涨血模型，正所谓过犹不及两个极端都不推荐，所以现在大家都主要讲的是贫血模型和充血模型）

领域模型，其实现在还是偏概念，一村一个样，都说自己领域驱动，但是它的用处不是专门修一段“黑话”的。

他其实针对单体大业务拆分微服务的一个解决思路，你微服务切分的好，那就是DDD用的好，反之亦然。这可能就是我目前对DDD的一个小的想法。