
158
|
第
7
章
我们应该思考更为普遍的情况,遵守前面讨论的规则,多种业务功能的选项会让产
品团队感到非常满意。
7.11
通过服务通信
正如
2001
年的贝索斯备忘录中所说,实现一个优秀的平台的方法是,所有通信只能
通过服务接口完成。服务必须拥有自己的数据。其他应用程序或服务不得走“后门”。
任何团队都不得直接从另一个团队(服务)的数据存储中读取数据。他们应该通过
服务接口通信。不允许团队直接通过链接、数据库级别的扩展查询、共享内存或特
定于供应商的数据处理扩展,来获取其他服务的数据。
服务是数据的主人,而且必须对这些数据负责,这些数据代表了领域的名词或功能。
在服务创建好后,所有其他的应用程序都应该使用该服务,而不应自行构建完全相
同或略不同的功能。
这意味着领域内的任何两个服务都不应重叠,或执行相同的工作。
7.12
对外公开
在本书中,我一直在强调,为了开发出更好的软件,我们必须减少假设。然而有一
种情况,在这种情况你下,做出假设或者至少做出一个模糊的期望,有助于提高设
计的弹性、性能和可扩展性。这个假设就是,编写的任何服务都可以对外公开,公
开到组织和应用程序之外,供其他业务部门使用,甚至公开到互联网上。
当然,此处我们需要把握平衡。如果根据近期的计划,没有公开服务的需要,而且
截止日期迫在眉睫,那么花费额外的时间为服务新建一个公共接口也不合适,因为
新接口(正如我们之前的讨论)需要单独构建和部署,并经历非常麻烦的变更请求
流程,而且如果没人打算使用该服务,则建立这样的接口没有丝毫用处,只会白白
浪费计算和存储资源。但这个假设的重点并不是完全照搬 ...