接口设计–可行与好的讨论
下文发表在公司内网博客。
正文
强烈推荐大家积极参与讨论，或许你的设计水平从此开始快速提高
发起讨论的来由:
最近要PDT系统要支持调度台发送长短信到手机的功能, 例如调度台一次运行发送200字短信. 手机目前只支持一次最多接收60多字的短信.
修改的逻辑很简单, 将长短信拆分成多条关联短短信, 例如在短短信前加”第一条,共X条”.
满足这个需求可以有很多种可行的修改方案, 可以在调度台界面[王凯]/调度台业务接口[孟宪宇]/调度服务器/SSU 等等模块修改，可以参见下图（图中DIP又分成调度台界面与调度台业务接口）
问题是在哪个模块改是最好的?
请给出理由和结论，如果你有参与负责短信发送的相关模块请标注出来
我觉得放到DTC中实现。
1. 控制系统中的最小变动。除了DTC,其他模块都不需要关心短信字节数的限制，当手机接收字节数扩充后，只需要改动DTC即可。
2. 如果放到调度台,Bgw,SSU,那么一条200字节的短信，就会分为4条短信发送，那么处理的总流程的数量就会变多。调度台>BGW>SSU>DTC。
所以放到DTC的处理流程最少了。
手机实现支持长短信，其它模块都无需更改，对系统的影响最小。
要看长短信到底有多长了，如果太长(比如超过1024个字节)，pSip协议栈都承载不了了，最终可能还是要在调度台上修改。至于在哪个部分修改大家再讨论。
如果手机能实现接收长短信，同时其他模块也支持，那么应该在手机上改；如果手机无法实现，但是其他模块都能实现，应该在DTC上改，以此类推。
原因是接口应该抽象的，不能依赖于下层实现，也不能直接依赖于上层实现；上层决定下层，下层提供接口的可行性验证，上下层都需要依赖于抽象，遵循上述原则才能使接口不易变，耦合度低，从而可维护性高。
本例中调度台界面是调度台业务接口的上层，业务接口是调度服务器上层，DTC是手机的上层，发短信的抽象是“发送方”“接收方”“短信内容”，字数属于实现细节，应该被抽象掉。
举例来说，现在的手机单条接收最大支持67中文字，调度台改成按67个字符分割长短信，如果其他厂商的手机或是其他项目中67变成了66，调度台就需要修改。这种依赖关系非常危险，调度台的实现依赖了那么下层的实现，调度台界面的通用性被污染了。
接口设计的另外一个原则是妥协，特别是接口的上下层是不同人负责，因为认识上的不同，站的角度不同，为了整体氛围、成本，使用被污染的接口，也是难免的。
目前是空口不支持长短信，所以需要系统侧改。
从接口合理性上，dtc改是最合适的，但是还要考虑其他外部因素。针对此问题，pdt联盟也讨论了n次，各个观点都有，最终定下来的结果是：交换机之间传递的短信仅支持短短信，系统内具体实现不做要求。如果放在dtc做，我们系统发出跨系统的短信，就需要交换机做拆分。结合我们的pdt系统，目前来看放在源头调度台改比较合适。
做设计的时候，遵循原则还是凭感觉（只看眼前的利益，当下改动少）？
有点像做人处事，例如遵循诚实的原则还是随机应变的撒谎？