理论系列二 架构与冗余

从数学原理上，从重构上来看，冗余是难以接受的。
但是在实际工程中，冗余确实最常见的问题解决方式。

比如数据库设计的范式，第一范式要求列不可分割，第二范式要求消除非主键依赖，第三范式要求消除传递依赖。

如果完全按照第三范式来进行数据库设计，那么将会造成大量的多表查询，平白给后端实现增加了难度，而第二范式也在数据库设计中禁止使用唯一键，平白给自己套上了枷锁。

计算机语言是人类语言的抽象，人类自然语言本身就有大量冗余。实际上，信息论的双重编码，也就是添加信息冗余。

今天在angular项目中，父子组件之间实现了业务UI分离，在遇到一个子组件重复代码时，我习惯性将重复代码抽出。结果造成了父子组件交互，子组件交互一系列过于复杂的设计，最后反应过来，接受了重复代码，设计的复杂度就降下来了，使得代码更易理解，方便后续的开发，也减少了技术债务。

将涉及算法和设计http交互的部分抽出成服务是第一步。

将几个子组件共同的UI逻辑抽出成事件是第二步。

与此同时子组件应该独立调用服务，独立调用UI，而不应该将这种调用也强加之于父组件。

换算成后端，控制器依赖于服务，服务依赖于数据访问接口，每一个都应该独立调用，如果非要实现服务依赖服务，那么就造成了服务与服务之间的逻辑联系，这在代码维护时会造成不便，假如一个服务依赖另一服务，如果依赖的服务变动，那么奈若何？

就架构设计而言层次调用最能清晰的显示逻辑关系。而同级调用则会造成混乱。

关于这一点，今天设计的angular的子组件时，我就想调用另外一个子组件的功能。

应该禁止使用同级调用。

关于这点，元芳你怎么看？