初见ddd，ddd落地，ddd见解

目前工作采取的是大中台，小前台策略，经过一段时间的工作后，也开始接手中台方面的工作，而我们中台采取的就是ddd架构。

背景：

还记得当时问技术经理为什么要用ddd而不是用传统的三层？他的回答是三层用到最后一定烂掉的。我对此深有体会，因为已经接手的前台项目就是经过了三批人，已经被改得面目全非，如果不花上一到两个月去熟悉和理解根本不敢下手去改，因此像中台这样“沉淀”下来的部分使用ddd会更加稳妥，生命周期也会更长。

ddd落地：

花了两三个月的时间去csdn上研究ddd的文章，只能理解个大概，没办法还是要实践出真知。我负责的工作任务是网络报销系统中的票据中台，先看比较简单的接口，以分享发票为例，先上代码分析：

这里的代码位于application层的command线中的实现类，在这里我们能看到ddd架构的冰山一角。我们可以看到先调用了billRepository来根据fileId和instanceId来获取billId，然后通过billId获取billAGG，那么到这里我们的主角已经出场了，在整个ddd架构中都是围绕agg做文章，那么在这里我们调用了agg自己自身的方法去添加票夹，这里就是对应着我们常说的充血模型，最后调用仓储层的billRepository去做一个保存，这个接口的功能就实现了。

对比：

1.到这里我们可以想一下如果用传统三层应该如何完成？大致的思路就是根据fileId查出billId后直接插入一条数据就结束了，简直不要太爽，但是仔细分析后发现，billRepository的三个方法是可以被多次复用的，同时agg的addFolders方法也是被多次复用，因此在第一次写的时候ddd会花费更长的时间，但是后续的开发证明这一定值得，可以看到分别被引用10次和14次

2.同时我们也能发现这个接口的业务逻辑主要是在agg内的方法，这是和三层很大的不同点，主要是因为addFolders是agg自身的行为，同时也不涉及跨领域domain

3.最后的保存我们可以看到入参是一个billAGG，也是和三层很大的不同点，在三层中我们保存的方法是构造表结构对应的po，但在这里我们是构造agg，在billRepository.save这个方法中封装了大量的代码，同时包括将agg转为对应的表结构，以及对应的数据库操作，后续会继续深挖。

初见ddd，不足的地方敬请谅解，后续会继续深挖ddd以及表达自己的观点和思考

纯手动码字，喜欢的点个赞，谢谢