GO学习记录3——DDD运用（Service、Domain和Repository）

GO学习记录（3）

DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。

一、Service & Domain Object

具体来说，在 DDD 里面，业务逻辑正常应该放在两个地方：

• Service
• Domain Object（领域对象）

Domain Object 上都没有什么方法，所以真正的业务逻辑是放在了 Service 里面。
注意在增删改查为主的项目里面，Service 这个部分是没有什么内容的。
在 DDD 的理论中，Domain Object 会用来承担很多的业务逻辑。
但是在互联网这一类的应用中，因为业务逻辑大部分都是存取数据，或者调用下游接口，所以 Domain Object 很多时候都难以用上。
在这种情况下，Domain Object 大部分时候只能看做是一个数据载体。
不过在实践中，还是应该尽量考虑把逻辑挪到 Domain Object 上。

二、Repository

总结来说：一切和存储有关的事情，都在 Repository 上处理。
Repository 最常见的做法就是集成了 DAO 和 Cache 操作。具体来说，Repository 要负责：

• 调用 DAO 和 Cache 的方法来读写数据。
• 负责解决缓存一致性的问题。
• 解决缓存预加载的问题。
• 如果在存储层面也有降级等治理策略，也可以在 Repository 层面上解决。

对于一个简单的增删改查应用来说，大部分代码应该都在 Repository 里面。
注意一点：大部分情况下，缓存与否，怎么缓存是技术问题，不是业务逻辑。
可以明确说，在 DDD 里面没有明确规定一定要有 DAO 或者 Cache 。
可以将 DAO 和 Cache 看成是实现 Repository 的一种方式。
在很多公司里面，Repository 之下并没有明显的 DAO 和 Cache 的概念。
如图，在一些公司里面不引入 DAO 之类的抽象，而是在 Repository 里面直接操作 DB 和 Redis。这不算是很好的实践，但是可以省去一些定义接口的时间。