2.1 组件定位：精准地解决共性问题

组件来源于软件工程实践中，是对重复、反复出现、普遍的、有相似性的问题进行分析，剥离掉各个问题的特性，而提取各个问题之间的共性。此共性就确定了组件要解决的问题。如果不是共性的问题，那么写完后的代码就只能在一种或有限的几种情况下才能被使用，就无法实现大规模复用。不能广泛地复用，就不能被叫做组件。

因此，组件首先是业务驱动的，不是技术驱动的。不能因为我们有了新的技术，就想着要写几个新的组件。

共性的业务问题，是组件的产生来源。

另外，即使确定了要解决的共性问题，组件也还必须提供解决问题最合理、最有效的方式和方法。如果提供的方法不是最好的，那么也很难得到使用者的喜爱，最终也难以推广和复用。因此，组件设计上，必须提供解决问题的精准思路和方案。这是决定同类别的组件中，哪个组件能胜出的最主要原因。

一个组件提供的问题解决方法，是否最有效，主要评价原则如下：

1.技术与业务对齐

技术结构和技术概念要与业务上的模型、概念保持一致，在组件对外暴露的接口上，最好不要引入新的技术术语和概念，这样的组件最吻合业务的需求，也最容易理解。

技术与业务对齐，这是组件设计的第一位重要原则。

2.技术方案的优势

这是结构设计、技术选型范畴内要考虑的问题。实现同一个功能，可以有很多不同的结构设计，也可以采用很多不同的技术。优秀的组件，一定要在技术方案上有明显的技术优势。

3.接口简单

组件暴露出来供外界使用的接口，必须足够简单。在概念和模型层面上与业务保持一致，另外接口封装、抽象上要仔细推敲，保证接口提供给别人使用时，调用者足够简单地使用。

4.功能强大

组件如果提供的功能太少，意味着能帮用户解决的问题比较少，这样的组件实用性大打折扣。而如果组件的功能过多，就会让用户觉得这个组件非常臃肿和庞大，用户只用了其中一小部分功能，其他大部分功能都用不上或者很少用，这样用户要在一本厚厚的使用手册中，仔细寻找自己需要的部分，去除自己不需要的部分，这也算不上一个优秀的组件。因此，一个组件提供的功能，既要能满足多种场景下不同客户的需求，还要在不同的需求中进行取舍和合并，使提供的功能集不会超出客户实际使用需求太多。