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

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

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

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

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

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

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

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