search

cs50Mu / knowledgeBase

read --> think --> write
0 stars 0 forks source link

DOMAIN DRIVEN DESIGN IN GO #5

Open cs50Mu opened 4 years ago

cs50Mu commented 4 years ago

https://www.citerus.se/go-ddd

代码：https://github.com/marcusolsson/goddd

Don’t Use Frameworks

cs50Mu commented 4 years ago

https://mp.weixin.qq.com/s/R-jBnPhWJHs7J-4CETV88A

美团技术博客：https://tech.meituan.com/2017/12/22/ddd-in-practice.html

cs50Mu commented 4 years ago

在研读goddd项目的过程中发现，它的数据持久层里的逻辑很简单，只有基本的CRUD，顶多是一点定制的查询，稍微复杂一点的业务逻辑都放在了domain model里了。

另外，猛然意识到，它的数据库查询是没有涉及到join操作的，然后就想知道这样做是不是故意为之的呢？搜索了一番，果然是有意为之的，主要是性能和可扩展性上的考虑，思路是：

摘抄一段「知乎」上的回答：

大多数项目，发展的后期，性能瓶颈都出现在了数据库上，然而在数据库上做优化的空间非常小。 相反，在应用上做优化的空间就大多了，比如集群，分布式，缓存等等，可以轻易地把计算压力分解到n台服务器上。

left join的目的无非是把两个模型上的数据合并到一个模型上，这是需要运算的，数据量越大运算量越大，更何况，数据库在left join的设计上，表现并不理想。

假如我们使用leftj oin，意味着省事，程序员把合并数据的过程交给了数据库，自己省去了一堆代码，可是，等以后，数据量大了，数据库忙不过来了，怎么办？怎么把left join数据库的压力分解到多台服务器上？也许会有很牛逼的数据库大师，可以想到很好的办法，但是大多数人，都会头疼。假如我们不用left join呢？数据库只干自己最擅长的:单表存和查。我们多写几行代码，帮数据库打了个杂，我们的程序运算量大了，我们很容易做集群，做分布式，做缓存，而且，单表查询，尤其是根据主键进行的单表查询，也很容易借助缓存，缓存本身又很容易集群。

看到了吧，压力分解变得简单多了，所以，避免left join,多写了点代码，别以为架构师为了让你工作更饱和，没事给你找事做，他让后面服务的承载力看到了希望

我在想，如果不太在意性能，或者没有高并发的需求，比如一些后台服务，是不是就没太大必要这样做了呢？但感觉这是一个好的实践，准备在项目中试试

参考：

cs50Mu commented 4 years ago

两篇介绍DDD的文章：

https://medium.com/tradeshift-engineering/my-vision-as-a-software-engineer-about-ddd-domain-driven-design-2f36ec18a1ec

https://medium.com/tradeshift-engineering/my-vision-as-a-software-engineer-about-ddd-domain-driven-design-part-2-973bcf5a9848

这篇也不错：https://techbeacon.com/app-dev-testing/why-you-need-domain-driven-design-even-though-you-think-you-dont

Many developers only have eyes for gadgets, technology, and tools, while business-related things are regarded as irrelevant inconveniences. But you can't help the business develop its capabilities without understanding the business.

cs50Mu commented 4 years ago

DDD中repository的设计，让我不免担心性能问题，搜索一番发现了这个回答：

DDD: do I really need to load all objects in an aggregate? (Performance concerns)

cs50Mu commented 4 years ago

一篇写的非常好的DDD文章：

后端开发实践系列——领域驱动设计(DDD)编码实践

这个也还行：

Re：从零开始的领域驱动设计

还有这位大哥的一系列帖子：CQRS初探