DDD领域驱动实践记录

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

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

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

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

 

 现在该分析业务了，这个是难点，对接这种任务主要就是服务方api的调用和我方业务的调用。Domian应该是业务的体现，是无论应用层怎么变，业务应该要能很少受影响。于是我们将对接的业务放在这里，将调用放到外部原本的应用层里。这里我画了个图，看样子应该挺像的

 

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

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

 

 

 

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

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