DDD领域驱动实践记录
虽然很早之前就已经了解过DDD相关的内容了,但一方面网上理论知识太过碎片化导致难以理解,另一方面实践内容太少导致想动手的时候无从下手。于是就渐渐淡忘了这方面实践的念头。
最近重新了解了DDD相关的知识,依旧是云里雾里,总感觉落实实在是困难,对领域模型,上下文限定什么的太过模糊,基本都很主观,依旧难以理解。甚至有想放弃的念头。
这时候刚好分配了一个对接电子发票的任务,需要新建个类库,我就在想能不能在实践中不管对不对先试试一个小型的DDD呢?
emmm。。先根据DDD分层架构的传统4层分层。User Interface放在类库不合适,忽略。Application目前内容应该很简单,而且不能更改原来的项目结构,忽略。 大头来了,Domain 这个是核心必须要有, Infrastructure可以有。于是项目结构就是决定了
现在该分析业务了,这个是难点,对接这种任务主要就是服务方api的调用和我方业务的调用。Domian应该是业务的体现,是无论应用层怎么变,业务应该要能很少受影响。于是我们将对接的业务放在这里,将调用放到外部原本的应用层里。这里我画了个图,看样子应该挺像的
因为是一个小型的实践产品,没有复杂的业务,没有复杂的交互,所以是很简陋的了。
相应的目录应该是这样的了
我以前一直以为像是一个api的返回参数与接受参数是entity,最近写的时候忽然觉得,其实这应该算Values,毕竟这个不影响真正的业务内容,而且只是传递值使用的,所以将之划分为了Values里面。
根据这个流程,作为聚合根的Business和外部交互,理论上应该是正常的。这个小小的实践,算是这一段学习的记录吧