第一次听说DDD这个词语，大概是2年前，在一次和某个大佬吃饭吹水的时候。后来再接触，是在工作中的某个迭代，被评为了迭代之星，可以选本书，然后就选了这本DDD。再之后，就没然后了（惭愧）。最近，转写前端的一个月中，又频频听到了这个词。也算有几次接触，心态也从：

卧槽，为什么这样搞？=> 嗯，分得开是挺好的 => 真香

现在， 有一些初次接触的感悟，也想后面能把DDD这本书读一读，再来回过头看看自己的认识是否到位。

不解

初次接触DDD，是在最近工作中，和后端去约定接口的时候。为了方便描述，这里Mock 一个场景：一个演出详情页，里面有演出的相关信息、艺人的相关信息、场馆的相关信息。按照经验主义，我认为一个前端的页面的所有信息在一个接口返回。

所以一开始，当后端没有在演出接口里面返回艺人和场馆的信息的时候，我认为是有问题的，并和后端同学沟通，后端同学说艺人、场馆都有单独的接口，演出里面已经给了演员ID、场馆ID了，你再去查就好了。我一脸黑人问号，不解为什么不一个接口全部都返回回来。后端同学只告诉我，他们之前都是这样做的（我是中途加入这个项目组的）。然后我带着疑问，先去看了现有项目中，发现果然是如后端同学所说。之前类似的页面是分别去请求了几个接口。自己想了一下，觉得这样对前端同学不太友好，也没想出来什么能过说服我自己的好处

恍然大悟

带着疑问，还是按照原来的方式，先把业务完成了。抽时间，去和 Leader 说了这件事。 Q：为什么前端一个页面分成几个接口去请求，而不像我们之前客户端，一个接口全都返回了。前端都是这样做的么？

A：不是前端都是这样做的，而是事情本来就应该这样做的。我们之前客户端没有这样做，不是因为之前是做的对的，而是历史遗留的问题。其实就是一开始就没设计好。

Q：那这样做有什么好处？

A：这样就把业务分的很开。演出信息就是属于演出自己的领域，它不会去关心艺人是如何描述的，也不会去关心场馆的信息。它只需要知道艺人是A，场馆是B就行了。至于艺人和场馆，他们都有自己单独的领域。

Q：还是不太明白这样做的好处。

A：首先，前端的展示，是多变的。今天演出详情长这样，明天就可能变了。今天还有艺人的信息，说不定明天就没了，多了一个促销的活动。所以，如果后端按照前端展示的去写接口，那么这个接口就可能会经常变动，这完全是不需要的。这样做一来增加了成本，二来也带了风险。

Q：（恍然大悟）有道理，这样后端的接口就不去依赖前端如何展示的了。如果要去做兼容，不想通过升级API的方式做（比如/api/v1、/api/v2），那么接口可能会越来越臃肿。我明白了，这可能是处理复杂性的设计原则。但是这样前端就会增加一些工作量，如果遵守一个原则带来了一些开发成本，那么落地就可能会有些难，特别是我们在写业务的时候，时间都紧迫，很有可能就会在这方面做妥协。所以有什么办法既让后端同学按领域去写接口，又让前端业务开发同学写起来更顺手。可能需要一个中间层？

A：是的，可以有个胶水层，这个胶水层，既可以是前端去写，也可以后端去写。之前点评是后端去做的。这个都可以，无所谓的。有了这个胶水层，就可以从API上定制返回的内容了。

---

~End~

一些反思

为什么自己一开始不能接受，或者说不理解？

经验主义害死人，之前在写客户端，一直都是一个页面一个接口，很少去请求多个接口的。所以潜意识里面就认为这样做是对的。所以第一##次接触的时候，认为这样做是不合理的。而且自己的视角太被前端局限了，没有从后端去思考。

为什么写了快四年的客户端，没有接触到这个东西？

首先，之前的项目太小，业务还没复杂到这个程度。票牛的 App 虽然业务有一定的复杂度，可能因为历史遗留原因，没有去设计。从而形成了这个不成文的约定。

其次，客户端不像前端，特别是iOS，是通过约束布局的，如果依赖了一个可有可无的元素，或者等网络请求回来再去插入一个元素，写法是很麻烦的。所以一般都是固定布局，然后等数据去渲染。但是前端是文档流，元素的插入删除很方便，特别是像React这种。所以，即使没有胶水层，前端也会比客户端更好实现。

Action

后面的工作中，虽然也频繁接触了DDD，但是终究是听来的，没有系统的去学习。所以要抽时间把DDD这本书读一遍，相信会有更深的体会。现在还有一个疑问，在划分领域的时候，怎么去拿捏粒度。希望这本书能给我个答案或者指引。

现在项目中，还没有把胶水层做起来。后面要去调研下，从前后端两个角度，如何去写胶水代码。