如何构建一个循证架构以优化决策过程？

本文共计1096个文字，预计阅读时间需要5分钟。

没有最好的架构，只有最合适的架构。循证架构是《Expert One-on-One J2EE Development without EJB》一书中推崇的架构思路，用我们的话来说就是摸着石头过河，找到最适合自己架构的方法。在SOHO，我们追求的就是这样的架构。

没有最好的架构，只有最合适的架构。循证架构是《Expert One-on-One J2EE Development without EJB》一书中推崇的架构思路，用俺们的话说就是摸着石头过河，找最适合自己的架构。

俺现在soho，大活不多，小活不断。我的工作具备以下特点：

（1） 根本没摸清楚需求的时间。需求都是从原型到Demo到版本1到版本2探索出来的。经常需求变化非常大，因此，必须以敏捷方法为基础；

（2） 一般没多少数据需要存储，顶多百万级；

（3） 需要极度的压榨开发效率。一个工作，10天完成和20天完成，那收益前者就是后者的两倍。

在上面（1）-（3）驱动下，俺摸索出的架构见下图：

从下往上，简单说说：

（1） 数据库：db4o。谁用谁知道，哈哈，爽。什么ORM，SQL，DataSet，统统是过眼云烟了。一切都是普通对象。数据库几乎是0设计。数据接入也非常非常的简单。

（2） Db4o之上得有一个逻辑层，来应付需求变化。这一层主要就是各种实体对象，需要良好的设计，否则，应付不了需求的变化。这一块我一般要设计比较完备的event体系，便于后期修改与组合。

（3） 服务层：主要是RIA应用需要。如果是Winform程序，不用这一层。

（4） UI逻辑层：最开始没弄这一层，最后鉴于在界面那一块太耗时间，就加了这么一层。