从编程思想到软件开发和设计能力培养( 五 ) 在和开发团队沟通的时候

所以回到软件开发里面，任何一个设计就是包括两个方面的内容：

其一是最终交付的功能的结构，底层的对象和模型是如何的？
其二就是基于底层对象模型如何最终形成完成的产品功能？

第1个对应到我们的逻辑模型，数据库设计等；而第2个对应到我们的用例分析和实现，或者类似活动图，状态图，序列图等动态实现等。
那么，当我们拿到一个复杂的业务功能的时候，我们基本的思路究竟应该是如何的？
首先通过完整的业务需求分析，找到具体的业务用例（业务功能点），把业务功能点本身的业务，流程描述清楚。在这个描述和定义过程中，先找到核心的业务对象，从业务对象，从业务对象识别出具体的数据对象，从数据对象抽象具体的对象类，或者定义具体的数据库表对象。简单来说就是，你要先通过业务的分析把关键的对象识别出来，这些对象最终再转成你底层的数据库设计，逻辑层的核心对象或实体类。
其次你就需要考虑底层的对象或模型如何协同和交互，最终实现你需要的业务功能。对于一个最简单的表单增删改查，你会发现这个过程很简单，就是录入数据存储到数据库，或者从从数据库查询出数据展现到界面表格里面，再复杂点的可能涉及到主从或多层表结构而已。
那么这理解究竟是哪里复杂了？或者说复杂的业务功能究竟是哪里复杂了？
这里并不是底层数据库表结构和关联关系复杂了多少，而是处理数据入库，查询数据出库的逻辑变复杂了。正是由于这个原因，你在分析任何一个业务功能实现的时候，不仅仅搞清楚简单的表单数据流，更加重要的是识别和抽象出关键的业务规则和逻辑。
这一点如何做？
你需要先考虑的就是要有一个分层思维，即前端实现和底层逻辑分层开，不是1对1绑定的，在拆分开后你就会考虑你的逻辑层应该如何规划类，有哪些实体类，有哪些专门的处理业务逻辑的类，有哪些进行业务逻辑组合等问题。
理解了这点，任何一个复杂的前端操作，本质就变成了：
前端操作 = N个DAO操作+N个逻辑方法操作的集成。
理解到这里，你会发现和我文章里面大量提到的SOA服务组装和编排思路完全一样，只是这个组装和编排不是通过服务设计器完成的，而是通过你的类似组合类或Facade类来完成的而已。
高级开发和设计，从技术流到问题域驱动
在日常接触中，我们经常会遇到一些开发人员，一说到主流的redis, spring cloud, rabbitmq等等都用过，都玩过，也感觉用的比较熟，但是在我们定义里面仍然是高级开发。是否具备设计能力重点仍然是前面讲的真正面对业务需求和功能时候的抽象能力，同时将问题域转换为最合适的对象和模型的能力。而对于上面各种主流开源技术仅仅是我们解决问题的工具。
我们开发一个系统，比如我们选择了spring cloud来做微服务架构，那首先要回答的就是面对当前业务域和问题，为什么要采用spring cloud架构，还是你认为当前大家都用这个架构所以我们也要用。
其次，你懂了spring cloud和各个组件的用法仅仅是熟悉了一种工具和技术平台，你要真正能将业务需求拆分为合适的微服务模块，识别和定义关键接口服务，抽象出共性组件，包括针对不同的非功能性需求，选择最合适的缓存，消息中间件等各种组件来解决问题，才是最关键的设计能力。
软件领域，一个好的设计一定是最合适+兼具扩展的设计，而不是采用最先进技术的设计。
开发人员的架构设计能力培养

文章插图
对于软件架构，架构思维，在我前面的博客文章里面已经多次谈到，实际上对于一个开发人员来讲，如果要真正成长为一个名出色的架构师是相当困难的。一个优秀的架构师可以说是同时具备了业务加技术，宏观加微观，抽象加实现多方面能力的整合。