从“简化“和“杠杆“的原则来看，你的这个方向和方法还是有点复杂了。测试的话，Amibroker, eSignal, Multicharts, TS都挺不错的，虽然要花点钱，但是很值。如果你还是觉得自己搞个回测平台，那么建议你使用 Excel，Matlab这类平台。如果你选择用C++，Java，.Net的话，希望你是一头真正的大牛，并祝你成功！
其实是有点像用某种语言去描述，和novaavon说的“伪码”，Toby提到的“DSL”差不多意思， 怎么去实现是细节上的问题，不过大方向是这样的， 策略是策略，驱动策略的引擎是另外的东西， 这样分开之后的好处很多....... 例如，一个好处之一： 论坛里面很多人发愁程序员实现策略的时候就知道了细节， 在我说的这个框架下面，几乎没有这种担心， 做引擎，做策略几乎各不相干，互相不关心（也没法知道）对方的细节。
框架方面，现有的平台不都是策略和引擎分开的么，如果你比人家的优秀，愿意分享就提出来供大家作个参考。一般的规律是平台用到的语言越简单，该平台实现的功能越少，执行效率越低。写策略用 DSL？伪码？？？既要马跑得快，又要马不吃草！别意淫了，学学语言吧。嫌难学学简单的，简单的都难，就请人帮你写算了。
看来espresso兄倾向于多使用现有的技术，减少开发周期。而我感觉c++开发个只给自己用的回测平台，也不一定会做得太复杂，好处是完全可控而且灵活。当然也可能遇到预料之外的问题，究竟如何只有自己试试看了 有时候一路闷头做下去会忽略许多东西，感谢espresso兄对“简化方法”这一点的提醒，中途停下来换个角度审视一下，也许就会找到更好的方案
"现有的平台不都是策略和引擎分开的么" ，这个，倒是真没有看出来， 我们说的似乎不是同一个东西。 大家不是就在这个帖子里面交流经验和想法了么？ 构架，设计思想这些东西看着很虚，但是确定了很多东西的大方向。 大方向不对，够你多忙好几年。 不过这些东西说多了用处也不大，大多数人不可能去做一个自己都不知道的东西。
DSL, 伪码的确是解决“策略”和“代码”分开的方法之一，所以说大方向是对的， 但是具体实现的话，再设计一种语言大可不必，我是最不喜欢重新造车轮的人。 发布一套这样的系统可能比长篇大论构架和思想更能解决很多人的问题， 但是现在还没评估好把这种系统发布出来的利弊， 之后打算在海洋做个咨询和调查再决定。
代码和策略分开，或者说用脚本解释器跑策略，这意味着要事先建设不少常用的功能库用于脚本调用。如果是下单通道，数据源，订单管理的接口偶认同；如果是用于策略开发，偶觉得这只够用于计算性能没多少要求的场合，流行商售程序交易平台就是针对这种需求；如果策略对计算性能敏感(不一定是高频交易)，那么开发基础模块再用脚本调用，反而工作量更多些吧。所以这里有个前提：自己的策略开发真不需要计算性能吗？
不知道您是否已经把这样的系统作出来了？从我的角度上说，这样的系统即使有，也是华而不实。用户层次上的易用和该系统的内部编码层次的复杂性是成正的。伪码之类的东西不是说做不出来，而是编码很复杂，而且能写得策略和现有的easylanguage之类的没有什么本质上的区别。做不了复杂的策略，又没有性能上的优势，仅仅是为了分开策略和代码，何苦呢？？况且，策略和代码不可能分开，也没有必要（分开有啥优点，分不开又如何？？），要想分开最好的方式就是你写策略，另一个人写代码。