企业应用架构模式（一）——细说企业应用的分层架构

        大型企业应用一般首先要将架构分为三层：表现层，领域层，数据源层。其中：

        表现层的责职是仅完成数据和输入与输出，以及所有的界面交互逻辑。

        领域层的责职则是完成所有的业务逻辑。

        数据源层则是完成数据库的存取操作。

        由此可以看出，表现层相当于领域层的一个用户。而领域层也相当于是数据源到的一个用户。在PHP开发框架中，实际并不存在领域层的代码。（所以，一些框架声称，它支持领域驱动设计，实际是懵人的！）当然，好的PHP框架，有可能会强制使用三层结构，从而实现领域驱动架构。但这样做，并不一定能够保证产生完美的领域驱动的应用架构。这就是说，任一项目仍需要项目经理，技术总鉴，或架构师对其进行规划与规范。

        很多人不解，为什么要分为三层。其实，这叫做，没吃过苦头，不知道疼。具体说来，有很多种情况，值得你这样做：

        其一：界面逻辑与界面是密不可分的，而当界面需求变化时，领域模型不一定需要变更。同样，领域模型中的逻辑有所变化时，界面逻辑不一定会同时变更。分开后，可以独立应对需求的变化。

        第二：这一点比上一点更加重要，那就是，不同的界面逻辑，可能需要相同的领域模型。这样，即保证了领域模型的共用性，不会出现重复的代码。因此，当你发现某一个地方有错时只需要修改一处。反过来，不同的领域模型，可能需要使用相同的界面逻辑。分开后，就不会使代码产生迪卡尔积的数量。而形成自由组合。

        第三：数据库移植。比如，有些大公司早期使用ORACLE。但后来，由于资金与数据的压力，不得不使用非O化（丢掉ORACLE）时，这时候，你要改的只有领域层，其它地方是不用动的。原因很简单，因为，你的数据源库层是框架实现的，肯定是多种数据库均支持的。但是领域层，则是与数据操作，特别是SQL相关的，则均是要改动的部分。

        第四：经过这样分层以后，才有可能对领域层采取更深的设计。比如，现在流行开放API，这就要求将领域层设计为：服务与事务脚本结构，或者控制器脚本与实体结构。当然，这两种结构的选择，则与所开放的API的实际需求有关。

        由此可见，一个好的架构通常有利于开发中应对需求的不断变化，有利于应用的升级与维护。也只有这样，才能实现快速高效地开发。