领域驱动设计杂谈
什么是领域驱动设计
领域驱动设计(DDD:Domain-Driven Design)，就是大家熟知的DDD，也就是我们经常说的六边形架构，说到DDD，一般都离不开红书《实现领域驱动设计》和绿书《领域驱动设计精粹》，我想每一个接触到DDD的同学对书中的内容都有很深的体会吧，但是我想正如一千个人心中有一千个哈姆雷特一般，从一年前最开始接触到DDD到现在这么长时间的一些学习实践，自己对DDD也有了一些自己的想法
DDD的分层设计一般可以理解四层，UI层，应用层，Domain(领域)层，还有基础设施层，看上面的分层我们可以很清楚的看到其实应用层只是很薄的一层，他的作用也只是说做将UI层的参数做一层转换，转换成我们的领域上下文中区，在DDD中核心的一层还是我们的Domain层，这一层包含有关领域的信息，是业务的核心
DDD的优点我在这里就不多阐述，这个仁者见仁智者见智，没有任何架构任何设计能说是完美的，也只有最合适的，对于一些复杂的业务系统能够做好领域划分，明确边界，做好领域模型的设计，能够更利于系统的维护，同时也更有助于更清晰的理解业务
关于实现DDD的一些想法
实现DDD的核心在于建模，这里推荐一篇文章四色建模，也是大佬推荐的，对于建模这块没有太多实践，不做太多阐述，但是一个好的模型对于整个业务系统是是至关重要的，DDD的核心在于如何划分领域边界，系统边界，以及如何做好模型设计，其他的技术选项啊，什么的相对来说都是次要的，在书中所讲到的一些实现，对于一些高并发分布式的系统不一定适用，最核心的还是领域驱动设计的思想
最开始刚学习DDD的时候，经常纠结一个问题，书中推荐的是直接使用一些ORM(JPA)框架来实现一个聚合根应该保证在同一个事务中的一致性，当然通过mybatis也能做，但是需要做一层数据模型到领域模型的转换，而如果直接设计聚合根和数据模型一致，能减少中间的转换代码，最开始我也是比较纠结的，那时候因为刚开始学习，对于这样的中间写了一大堆转换逻辑的代码多少是有些无奈，不知道这样的意义何在，一次次转换多少还有些性能损耗，但是也是微乎其微
但是如果你现在问我会怎么做，我会毫不犹疑的说，领域模型必须和数据模型分开，转换是有必要的，为了保证领域模型的纯粹，只做业务逻辑，转换层约定好与Domain层进行交互的出入参，或者可以定义一个网关，这样虽然说代码量增多了，但是却能保证假如数据模型变更或者领域模型做变动的时候，不会彼此影响
啥时候使用DDD，我觉得这个没有一个硬性标准，也还是要结合具体的业务场景和当前公司的一个现状，如果说公司业务当前飞速发展，随时可能会有一些大的业务上的调整，而且我们又需要快速的做业务的迭代，那么这个时候业务及其不稳定的情况下，如果使用DDD可能会在建模以及模型重建上耗费时间，如果说业务相对稳定，那么做一次DDD重构也不是什么坏事，毕竟通过DDD可以让我们离代码即文档你的更近
