DDD领域驱动实践记录

虽然很早以前就已经了解过DDD相关的内容了，但一方面网上理论知识太过碎片化致使难以理解，另外一方面实践内容太少致使想动手的时候无从下手。因而就渐渐淡忘了这方面实践的念头。

最近从新了解了DDD相关的知识，依旧是云里雾里，总感受落实实在是困难，对领域模型，上下文限定什么的太过模糊，基本都很主观，依旧难以理解。甚至有想放弃的念头。

这时候恰好分配了一个对接电子发票的任务，须要新建个类库，我就在想能不能在实践中无论对不对先试试一个小型的DDD呢？

emmm。。先根据DDD分层架构的传统4层分层。User Interface放在类库不合适，忽略。Application目前内容应该很简单，并且不能更改原来的项目结构，忽略。 大头来了，Domain 这个是核心必需要有， Infrastructure能够有。因而项目结构就是决定了

 

 如今该分析业务了，这个是难点，对接这种任务主要就是服务方api的调用和我方业务的调用。Domian应该是业务的体现，是不管应用层怎么变，业务应该要能不多受影响。因而咱们将对接的业务放在这里，将调用放到外部本来的应用层里。这里我画了个图，看样子应该挺像的

 

 由于是一个小型的实践产品，没有复杂的业务，没有复杂的交互，因此是很简陋的了。

相应的目录应该是这样的了

 

 

 

 我之前一直觉得像是一个api的返回参数与接受参数是entity，最近写的时候突然以为，其实这应该算Values，毕竟这个不影响真正的业务内容，并且只是传递值使用的，因此将之划分为了Values里面。

根据这个流程，做为聚合根的Business和外部交互，理论上应该是正常的。这个小小的实践，算是这一段学习的记录吧