基于.Net架构设计之四

针对前面提到的一些应用场景,我们应该如何利用.Net平台来搭建基础架构呢?

首先我们先详细的分解一下业务场景,将应用分层,然后针对每个层次我们来分析一下,系统架构应该作些啥。

基于.Net架构设计之四_第1张图片 

 

上面表述的是订单处理的部份场景,订单的提交可以通过在线网店,也可以通过客服系统,而作为基础功能模块的即时消息服务在多个业务模块中被消费。图中箭头方向表示依赖或调用方向,红色箭头表示服务调用,粉色块表示可能的独立部署单元,蓝色块表示逻辑上的层次,灰色块表示子业务模块。

图中层次的划分有以下几点考虑:

一、契约层包括数据契约和服务契约,而实体也是支持序列化的,但之所以不把实体直接暴露给服务消费者而是重新包装数据契约,是因为契约是面向客户的,我们应以最小知识原则,使契约尽可能的明确、简单、直观。但实体一般都会有很多辅助信息及验证信息,并且会有继承层次,虽然数据契约也可以支持一定程度的继承,但我觉得作为交互依据的契约,还是以一种无继承的单层次的方式呈现给客户更好一些,另外,当服务的调用者为异构系统时,简单的契约也就意味着更好的兼容性。

二、数据访问层也仅是对针对数据持久层的直接包装,并且应该基于IDbConnection/IDbCommand/IDataReader/IDbTransaction等通用接口开发,这样便于不同数据持久层数据库产品的切换。

三、业务处理层是整个业务逻辑的核心,它应该充分利用面象对象编程的灵活性,对于更上一层的业务处理层,可以引入工作流程来组装底层服务。

四、图中红色箭头杂乱无章,耦合度太高,可以通过调停者模式,引入第三方服务定位服务,减少相互之间的依赖。

你可能感兴趣的:(基于.Net架构设计之四)