- 应用架构
- 物理数据流图
- 信息技术架构
- 系统设计的应用架构策略
- 建模信息系统应用架构
1.应用架构
应用架构说明用于实现一个或多个信息系统的技术，作为详细设计、构造和实现的提纲。
2.物理数据流图
物理数据流图建模作为信息系统一部分实现的技术设计决策和人为设计决策，将同那些实际构造和实现的人沟通技术选择和其他设计决策。物理DFD将作为系统构造和实现的技术性蓝图。最开始，这种技术是结构和分析和设计的一部分，当然这种技术属于劳动密集型的方法学，有很大一部分被抛弃了，但是逻辑DFD和物理DFD技术仍然存活并被大量使用。
过程是DFD的主要形状，所以DFD称为过程模型。物理DFD描述了每个过程计划的实际实现。在实际应用过程中，每个逻辑过程都要拆分成多个物理过程，这可以描绘出应用的分布，包括人工操作。一般来说，物理过程的数量总是多于或者等于逻辑过程的数量，最重要的是物理DFD反映了所选实现策略需要的所有手工过程和计算机过程。
任何DFD中的所有过程都必须至少拥有一个输入数据流和一个输出数据流。外部代理从逻辑DFD中继续不变的转至物理DFD。只有需求变化才能激发对外部代理的更新。物理数据存储实现了逻辑数据存储，物理存储结构有多种格式，例如数据库、电子文档、纸质文件等等。
物理过程、数据流、外部代理、数据存储构成了物理数据流图。物理数据流图为信息系统应用建模计划的架构，然后基于物理DFD为每个数据流和数据存储设计内部和外部的细节。
3.信息技术架构
分布式系统是一种将系统构件分布到计算机网络多个地点的系统。分布式系统成为主流是因为客户的实际应用场景更贴近它，虽然分布式系统的复杂性要超过集中式系统。分布式信息系统架构有三种形式：文件服务器架构、客户/服务器架构、基于因特网的架构。
文件服务器架构是基于局域网的方案，服务器上仅装载了数据层。操作过程中先将文件下载到客户端，锁定文件，然后更新，最后上传并解锁。对同一个文件多人操作的时候容易出现脏读或者超时，客户端必须是胖客户端。
客户/服务器架构，这种架构是CS模式，除了部分应用软件，现在很少有见到这种架构模式的，生存场景变少了。
基于因特网的计算机架构，这种架构是CS模式，现在在中国属于非常流行。这种结构模式有非常好的环境适应性，虽然几年前客户端兼容让人很头疼，不过现在浏览器升级，兼容问题已经越来越少了，生命力愈发强大。
分布式关系数据库管理系统可能是基于BS结构的，也有可能是CS结构的，具体的架构选择需要根据业务实际场景考虑。数据在分布式数据库系统中分布也有很多形式，例如一条记录某些字段是分布式的，还有记录存在备份记录。
接口的架构要考虑很多业务场景，例如批量处理接口、单笔业务处理接口、实时处理接口、远程异步处理接口、用户输入操作接口等等。可以掌握多种接口的技术，实际使用由场景决定。最可怕的就是打着重构和重复使用的口号，使用不符合业务场景的接口技术，完全不知道技术选型错误的危害。
在应用结构中，还有需要考虑的是三方之间的电子数据交换，例如支付类的数据交换；图像和文档交换，这会受IO的效率影响；中间件技术，帮助我们屏蔽比较麻烦的分布式系统构件之间通信问题，但是运维还要自己去支持的。
4.系统设计的应用架构策略
在企业应用架构策略中，组织开发一个企业级信息技术架构，所有后续的信息系统开发项目都要遵循这个架构。这个信息技术架构定义了一下内容：
- 被认可的网络、数据、接口和过程技术及开发工具
- 集成遗留系统和技术到应用架构的策略
- 连续地检查应用架构正确性、适应性不断进行的过程
- 研究新兴技术并推荐将其纳入应用架构并不断进行的过程
- 对认可的应用架构修改请求的分析过程
当然这些看上去都比较明确，但是不排除初始的系统架构本身有问题，导致最后的技术架构问题更严重。这种案例并不少见。
如果仅仅只是针对独立项目或者是小项目，其技术架构相对独立，要评估技术架构的技术可行性、运行可行性、经济可行性。
5.建模信息系统应用架构
物理DFD将为详细设计和构造提供指导，可以快速确定设计单元。绘制物理DFD和逻辑DFD机制是完全一样的，正确性规则也是一致的。物理DFD提供的设计需要满足：
- 可工作的系统
- 实现了在逻辑DFD中说明用户需求的系统
- 提供了足够性能
- 实现足够的内部控制
- 适应需求不断变化和系统改进
创建物理DFD的前置条件是逻辑数据模型、逻辑过程模型、保存前两者的资料库。
第一个物理DFD是网络拓扑DFD，它描述了服务器和其物理位置、客户端和其位置、处理器说明、传输协议。这是一幅系统的物理模型图。物理DFD中物理数据存储结构需要详细说明这个数据结构是单数据服务器还是分布式的数据服务器，是主数据还是主副本，是文件存储还是数据存储形式，包括数据库的选型等等。除了从逻辑DFD中划分出更加详细的物理过程，还要明确人机边界的处理，当然人机边界的处理必须考虑场景、人的体验等。
不管现在我们面对的什么样的应用架构，可能是20年前的，也可能是新的，都要认真考虑，让应用架构的生命力更加强大一些，不至于挖出的坑把自己坑了！