架构设计感想

1. 架构设计复杂性

系统架构设计本身就是一件非常复杂事情。因为架构设计没有什么规章制度可寻。他的复杂性来源真实世界的复杂性。

现实世界的复杂性导致业务系统的复杂性，他不允许把系统的各个方面都在一个人的脑袋里面，因为信息量太大，那么必须要进行系统分解，当系统处于分解状态时候，处于子系统状态的时候，  把系统合并起来，流程可以跑通，全流程的可以跑通过至关重要。全流程的跑通有一定的风险性。面临联调风险。

当系统处于比较小型的系统时候，处于比较简单系统的时候，这种联调的风险还不是很大，甚至可以通过几个，若干高级程序员来控制住。

那么一个系统的开发模式就是把子系统分配一下，A 做 A 这个子系统 ， B 做B 这个子系统 ，

当系统处于比较大型的时候，并且一旦出现子系统之间耦合依赖，你中有我，我中有你的场景时候 ，这种联调的风险更加危险。

如果一个子系统的业务有是相当不熟悉，涉及到领域模型的时候，那么子系统既要完善自己的业务，同事也要兼顾其他的系统的设计，那么联调的风险更加变大，变得复杂。

因为如果一个子系统是一个大家不熟悉的系统，比如合约系统，这个系统又要跟钱包系统打交道，他要利用钱方面。而钱包系统又要跟otc 模块打交道，他必须有是一个通用的设计。合约本身要设计处于自己的东西，同时也要兼顾钱包的设计。

合约系统作为系统的调用方他对钱包系统的依赖，必须要合约系统自己去解决。必须要合约自己去拉通来进行设计。 

消费方主导设计，钱包没有办法去整合合约系统的设计。

 

2.全流程的跑通依赖什么东西 

（1） 需求的完整性，整个需求是完整的，并且要识别合约系统在其他子系统中需求部分。就像扫地一样，必须要把所有的角落都扫起来，扫干净。

很多需求是交互在一起的，必须要整体考虑这些需求，而不能分散，独立的考虑这些需求。

（2）PDM模型的完整性

设计一个子系统的PDM模型 ，模型的完整复述需求说明， 那么整体模型管理方面有是一个问题，大型模型设计，又分系统，分模块的模型整理方面有是异常的困难，采用liquibase管理系统的表结构。 一个系统只能有一个liquibase文件，避免出现整体依赖的问题，同时数据库模型作为一个交流的媒介，全局属性本身也是

模型方面采用抽象，模糊设计。一种抽象，模糊设计系统之间模型设计至关重要。子系统和子系统之间的模型利用抽象，屏蔽子系统细节，只考虑子系统中关联信息。

（3）接口相关性设计

当你的设计出来滞后，接下来就是接口相关设计，设计什么样的接口完成相关的功能，在配合单元测试保证接口功能OK