领域驱动设计中的分层模型

极客时间《如何落地业务建模》学习笔记 07，题图来自网络

06 | 跨越现实的障碍（下）：架构分层就对了吗？

能力供应商（Capability Provider）模式，听上去很有吸引力啊。

第一次知道，原来 David Wheeler 的“计算机科学中的所有问题，都可以通过引入一个间接层解决”，后面还有一句，“除了有太多的层以外”。

原文似乎是：

Any problem in computer science can be solved with another level of indirection. But that usually will create another problem.

就好像说“成功是九十九分的努力加上一分天才”，然后国人又续了一句。

Genius is one percent inspiration, ninety-nine percent perspiration.

我一直很喜欢 Ruby on Rails，但是确实没有考虑过它对于领域驱动设计的颠覆，而且现在 Ruby on Rails 的职位比较少，大部分是在维护老版本的系统。

使用能力供应商的多层架构，比起分层模型（把基础设施放在最底下）来确实漂亮。

基础设施不是层

把基础设施层放在旁边，确实清楚了很多。

这里似乎有两幅图是重复的？

关联对象、角色对象和上下文对象的元模式（Meta Pattern），不明觉厉？

对于思考题，能力供应商模式将显式的依赖关系转化为隐式的依赖关系，我觉得应该还好吧，似乎微服务也是这么处理的，从能力供应商模式的分层架构图来看，对于基础设施层的一些改变，比如换个数据库什么的，似乎对于领域模型层不会有太大的影响，而知识仍然是保存在领域模型层中的。

我也觉得能力供应商模式和防腐层不太一样

不要用解决方案去定义问题，而是根据问题寻找解决方案

可惜，我觉的目前大部分情况下，我们都是手持锤子满世界去找钉子，我现在手里的锤子是知识图谱。