小故事：架构师需要做什么？
2016-02-15 18:17:18 来源： mengyidan1988 评论：0 点击：
本文是一篇模仿问答的小故事，作者用幽默的风格简单分析了架构师要做的工作： 我想要成为一名软件架构师。 引用这是年轻软件开发者很好的选择。 我想要带领团队，并在数据库与框架、webserver等方面作出重要的决策。 引用噢，那你根本就不想成为软件架构师。 我当然想了，我想要成为重要决策的制定者。 引用那很好，不过你列出的内容中并不包含重要的决
本文是一篇模仿问答的小故事，作者用幽默的风格简单分析了架构师要做的工作：
我想要成为一名软件架构师。
我想要带领团队，并在数据库与框架、webserver等方面作出重要的决策。
我当然想了，我想要成为重要决策的制定者。
什么意思？你是说数据库并不是重要的决策，你知道我们在上面花了多少钱吗？
你怎么能这样讲？数据库是系统的核心，是进行所有数据系统化、分类、编入索引和存取工作的地方；没有数据库的话，就不会有系统。
辅助？这太离谱了。
嗯，没错，不过必须重新进行编码，因为在原本的数据库中这些工具都用到了。
什么意思？
这简直是疯了。如何创建不使用那些工具的业务规则呢？
那么如何在不了解使用什么工具的情况下，获得业务规则呢？
你在胡言乱语。
一派胡言！高层准则（假设指的是业务规则）调用低层准则（假设指的是数据库）。因此高层准则会根据调用方依赖被调用方的原则，而依赖低层准则。这个谁都知道！
得了吧！怎么能在不提及的情况下进行调用呢？
面向对象是关于真实世界的模型创建，将数据、功能与有凝聚力的对象相结合。是关于将代码组织成直观的结构。
大家都知道，这是显而易见的真相。
好吧，那要怎么做？
没错，这是当然的。
这取决于所使用的语言。在Java中，sender至少知道receiver的基础类型。在Ruby中，sender至少知道receiver能够处理所收到的消息。
是这样，好吧，确实如此。
是这样，没错。我了解了。不过sender仍旧依赖于receiver。
不会吧！sender仍依赖于它所发送的类。
下面是receiver：
是啊，不过你在撒谎，你把receiver的接口放在sender类中了。
懂什么？
如果这意味着我必须使用嵌套类，那么……
好吧，等一下。这又跟数据库有什么关系？我们最开始讨论的可是数据库。
业务规则没占多大份量。
好的，那么Gateway到底是什么？
注意：这是在businessRules之中。
ok，Something类又是什么？
另外，注意业务规则在运行时调用数据库；不过在编译时，数据库会涉及并依赖于businessRules。
好吧，我想我明白了。你只是在利用多态性来隐藏从业务规则实现数据库的事实。不过仍需要一个接口，向业务规则提供所有的数据库工具。
不，完全不是这样。我们没有尝试向业务规则提供数据库工具。而是通过业务规则，为它们所需要的内容创建接口。实现这些接口就能调用合适的工具。
是啊，不过如果所有业务规则需要用到每个工具，那么只需把工具放在gateway接口中。
啊，我看你还是没明白。
明白什么？这已经很清楚了。
等一下，你说什么？
不过，这意味着需要很多接口，以及很多的小型实现类，它们又会调用其他的数据库类。
不过这太乱了，浪费时间。为什么要这样做呢？
得了吧，为了代码，弄出来一大堆代码。
这是什么意思？
是啊，我是这样想的。
是啊，你说那些都不重要。只是不相关的内容。
不过必须得先决定那些吧！
胡说，我完全不明白你的意思。
作者：Robert C. Martin?
原文：A Little Architecture?
译者：孙薇
我想要成为一名软件架构师。
引用
这是年轻软件开发者很好的选择。
我想要带领团队，并在数据库与框架、webserver等方面作出重要的决策。
引用
噢，那你根本就不想成为软件架构师。
我当然想了，我想要成为重要决策的制定者。
引用
那很好，不过你列出的内容中并不包含重要的决策，这些都是不相关的决策。
什么意思？你是说数据库并不是重要的决策，你知道我们在上面花了多少钱吗？
引用
也许花的太多了。但是，数据库并不是重要的决策之一。
你怎么能这样讲？数据库是系统的核心，是进行所有数据系统化、分类、编入索引和存取工作的地方；没有数据库的话，就不会有系统。
引用
数据库只是一个IO设备，它恰巧为分类、查询与信息报告提供了一些有用的工具，但这些都只是系统架构的辅助功能而已。
辅助？这太离谱了。
引用
没错，就是辅助。系统的业务规则也许能够利用其中的一些工具，不过那些工具却并非相应业务规则所固有的。需要的话，可以用不同的工具来替换现有的这些；而业务规则不会改变。
嗯，没错，不过必须重新进行编码，因为在原本的数据库中这些工具都用到了。
引用
那是你的问题。
什么意思？
引用
你的问题在于，你以为业务规则是依赖数据库工具的，实际上并不是。或者说至少，在提供优秀架构前并不应当是这样的。
这简直是疯了。如何创建不使用那些工具的业务规则呢？
引用
我不是说它们没使用数据库的工具，而是说它们并不依赖于此。业务规则无需知道你使用哪个数据库。
那么如何在不了解使用什么工具的情况下，获得业务规则呢？
引用
让依赖倒置过来，使得数据库依赖业务规则。确保业务规则不依赖于数据库。
你在胡言乱语。
引用
恰恰相反，我在使用软件架构的语言。这是依赖倒置原则：低层准则应当依赖高层准则。
一派胡言！高层准则（假设指的是业务规则）调用低层准则（假设指的是数据库）。因此高层准则会根据调用方依赖被调用方的原则，而依赖低层准则。这个谁都知道！
引用
在运行时的确如此。不过在编译时，我们想要的是依赖倒置。高层准则的源代码应当不提及低层准则的源代码。
得了吧！怎么能在不提及的情况下进行调用呢？
引用
当然没问题。这就是面向对象的所涉及的内容。
面向对象是关于真实世界的模型创建，将数据、功能与有凝聚力的对象相结合。是关于将代码组织成直观的结构。
引用
他们是这么说的？
大家都知道，这是显而易见的真相。
引用
没错，确实如此，然而，在使用面向对象准则时，的确可以在不提及的情况下进行调用。
好吧，那要怎么做？
引用
在面向对象设计中，各个对象会彼此发送消息。
没错，这是当然的。
引用
而sender在发送消息时，并不知道receiver的类型。
这取决于所使用的语言。在Java中，sender至少知道receiver的基础类型。在Ruby中，sender至少知道receiver能够处理所收到的消息。
引用
没错。不过在任何情况下，sender都不知道receiver的具体类型。
是这样，好吧，确实如此。
引用
因此，sender可以在不提及receiver具体类型的情况下，设计receiver执行某个功能。
是这样，没错。我了解了。不过sender仍旧依赖于receiver。
引用
在运行时的确如此。不过编译时则不同。sender的源代码并不会提及或者依赖receiver的源代码。事实上receiver的源代码依赖于sender的源代码。
不会吧！sender仍依赖于它所发送的类。
引用
也许从某些源代码来看，会更清楚一些。下面这段是Java写的。首先是sender：
package sender;public class Sender { private Receiver receiver; public Sender(Receiver r) { receiver = r; } public void doSomething() { receiver.receiveThis(); } public interface Receiver { void receiveThis(); }}下面是receiver：
package receiver;import sender.Sender;public class SpecificReceiver implements Sender.Receiver { public void receiveThis() { //do something interesting. }}引用
注意：receiver依赖于sender，SpecificReceiver依赖于Sender，在sender中并没有receiver相关的信息。
是啊，不过你在撒谎，你把receiver的接口放在sender类中了。
引用
你开始懂了。
懂什么？
引用
当然是架构的原则。Sender拥有receiver必须实现的接口。
如果这意味着我必须使用嵌套类，那么……
引用
嵌套类只是实现目的的手段之一，还有其他办法。
好吧，等一下。这又跟数据库有什么关系？我们最开始讨论的可是数据库。
引用
再看一点代码吧。首先是一个简单的业务规则：
package businessRules;import entities.Something;public class BusinessRule { private BusinessRuleGateway gateway; public BusinessRule(BusinessRuleGateway gateway) { this.gateway = gateway; } public void execute(String id) { gateway.startTransaction(); Something thing = gateway.getSomething(id); thing.makeChanges(); gateway.saveSomething(thing); gateway.endTransaction(); }}业务规则没占多大份量。
引用
这只是个例子。还能有更多这样的类，实现很多不同的业务规则。
好的，那么Gateway到底是什么？
引用
它通过业务规则提供了所有数据存取方法。按以下方式实现：
package businessRules;import entities.Something;public interface BusinessRuleGateway { Something getSomething(String id); void startTransaction(); void saveSomething(Something thing); void endTransaction();}注意：这是在businessRules之中。
ok，Something类又是什么？
引用
它代表着简单的业务对象。我将它放在entities之中。
package entities;public class Something { public void makeChanges() { //... }}引用
最终BusinessRuleGateway实现，这个类知道真正的数据库：
package database;import businessRules.BusinessRuleGateway;import entities.Something;public class MySqlBusinessRuleGateway implements BusinessRuleGateway { public Something getSomething(String id) { // use MySql to get a thing. } public void startTransaction() { // start MySql transaction } public void saveSomething(Something thing) { // save thing in MySql } public void endTransaction() { // end MySql transaction }}引用
另外，注意业务规则在运行时调用数据库；不过在编译时，数据库会涉及并依赖于businessRules。
好吧，我想我明白了。你只是在利用多态性来隐藏从业务规则实现数据库的事实。不过仍需要一个接口，向业务规则提供所有的数据库工具。
引用
不，完全不是这样。我们没有尝试向业务规则提供数据库工具。而是通过业务规则，为它们所需要的内容创建接口。实现这些接口就能调用合适的工具。
是啊，不过如果所有业务规则需要用到每个工具，那么只需把工具放在gateway接口中。
引用
啊，我看你还是没明白。
明白什么？这已经很清楚了。
引用
每个业务规则只为自己所需的数据访问工具定义一个接口。
等一下，你说什么？
引用
这就是接口隔离原则（Interface Segregation Principle）。每个业务规则类只用到数据库的某些设施。因此，每个业务规则提供的接口只能访问相应的设施。
不过，这意味着需要很多接口，以及很多的小型实现类，它们又会调用其他的数据库类。
引用
很好，你开始理解了。
不过这太乱了，浪费时间。为什么要这样做呢？
引用
这样做能够条理分明，节省时间。
得了吧，为了代码，弄出来一大堆代码。
引用
恰恰相反，通过重要的架构决策，可以延缓不相关的决策。
这是什么意思？
引用
记得最开始，你说想做软件架构师不是吗？你想要作出所有真正重要的决策。
是啊，我是这样想的。
引用
你想要决策的是数据库、webserver和框架相关的方面，对吗？
是啊，你说那些都不重要。只是不相关的内容。
引用
没错。就是这样。软件架构师所作出的重要决策指的是，让你不对数据库、webserver和框架进行决策。
不过必须得先决定那些吧！
引用
不用的。事实上，在开发周期中，这些都可以稍后再决定，在信息更充足的时候再决定。
如果架构师提前确定框架，却发现框架无法提供所需的性能，或者带来了无法忍受的约束，这就成了灾难。
只有架构师决定推迟决策，待信息足够时才作出决策；在架构师的决策下，不使用缓慢而过于耗费资源的IO设备和框架的团队，才能创建快速、轻量级的测试环境；只有其架构师关心真正重要的东西，延缓那些不重要的，这样的团队才是幸运的团队。
如果架构师提前确定框架，却发现框架无法提供所需的性能，或者带来了无法忍受的约束，这就成了灾难。
只有架构师决定推迟决策，待信息足够时才作出决策；在架构师的决策下，不使用缓慢而过于耗费资源的IO设备和框架的团队，才能创建快速、轻量级的测试环境；只有其架构师关心真正重要的东西，延缓那些不重要的，这样的团队才是幸运的团队。
胡说，我完全不明白你的意思。
引用
好吧，还是好好看一下本文，不然只能再等10年你才能明白了。
作者：Robert C. Martin?
原文：A Little Architecture?
译者：孙薇
上一篇：Apache Ignite(四)：基于Ignite的分布式ID生成器
下一篇：通过利用“业务映射”来构建敏捷组织
分享到：
收藏
收藏
