任何交易系统的生存期都可简化为开仓和平仓。这一点毫无疑问。但如果涉及到算法的实现，则有多少编程人员就有多少种选择。每个人都会以自己的方式来解决同样的问题，但殊途同归。
经过多年的编程实践，各种构建“EA交易”的逻辑和结构的方法已一一试遍。现在可以说已开发出用于所有代码的清晰的模式模板。
大多数人采用的设计算法的基本方法，是从开仓起追踪持仓直至平仓。这是一种线性方法。若您想要对代码进行更改-由于有大量的条件出现且代码累积带来新的分析方向，这通常会导致极其复杂的情况。
建立交易机器人模型的最佳解决方案是“服务于条件”。其基本原则是–不要分析该“EA交易”条件和其持仓以及订单是如何发生的-而是分析我们现在要如何做。该基本原则从根本上改变了交易的管理并简化了代码的开发。
接下来考虑更多细节。
正如前文所述，“EA交易”并不需要知道当前状态是如何达成的。它需要知道的是，根据环境现在要做什么（参数值、存储的订单属性等）。
该原则和“EA交易”存在于从循环到循环（特别是从订单号到订单号）的事实直接相关，它无需关心订单在上一订单号发生的事情。因此，您必须使用事件驱动的方法管理订单。换言之，“EA交易”在当前订单号保存自己的状态，作为下一订单号相关决策的出发点。
该方法是线性的，它将占用“EA交易”不确定的时长。
因此，不循环“EA交易”而是存储删除订单的顺序才是正确之举，这样在每个新的订单号处尝试删除挂单时都会检查该订单。在这种情况下，“EA交易”通过读取状态参数就会知道，在这一刻它必须删除订单。然后它将尝试删除订单。如果发生交易错误，“EA交易”将只会在下一个循环开始前阻止进一步的分析和工作。
1.2.设计的第二个主要原则-尽可能地抽象化考虑的持仓方向（买入/卖出）、货币和图表。所有“EA交易”的功能应以这样一种方式实施，即仅在确实无法避免的极少数情况下分析方向或交易品种（例如，在您考虑开仓的有利价格增长时，尽管存在避免细节的不同选项）。始终尽量避免此类“低水平”设计。这将减少代码和至少两次的函数编写过程。并且可以实现“独立于交易”。
该原则的实施是用宏函数取代订单类型、交易品种参数和依赖性计算参数的显式分析。在后续文章中我们将详细介绍该实施。
在实践中，我们可以说，最佳方法是将“EA交易”操作划分为单独的函数。我想您一定会同意，在一个函数中编写“EA交易”的整个算法是很困难的，而且这也使后续的分析和编辑复杂化。所以我们在MQL5中要避免这样做，尤其是MQL5现在几乎可提供对环境的完全控制。
因此，逻辑语义（如开仓订单、追踪订单、平仓订单）应根据对环境参数和事件的完全分析彼此单独实施。通过这一方法，“EA交易”的设计变得灵活起来。您可以很容易地向其添加新的独立模块而不会影响现有模块，或是禁用现有模块而无需更改主代码。
1.指标。一个例子是对指标线条值、它们的交叉和组合等的分析。同时，指标可以是：当前时间、从网络获得的数据等。在大多数情况下，指标事件用于以信号指示订单开仓和平仓。较少用于它们的调整（通常为指标的追踪止损订单或挂单）。
例如，指标的实际实施可以是调用一个“EA交易”，该“EA交易”分析快速和慢速MA与沿交叉方向的进一步开仓的交叉。
2.现有订单、持仓及其状态。例如，当前损失或利润规模、存在/不存在持仓或挂单、已平仓持仓的利润等。由于相比指标事件它们的关系存在更多选项，这些事件的实际实施要远为宽泛和多样化。
仅基于交易事件的最简单的“EA交易”示例是重新填入以平均现有持仓，然后将其输出至所需利润。换言之，可用持仓存在的损失将成为下达新平均订单的事件。
或，例如，追踪止损。在价格从上一止损以指定的点数移动至利润时，该函数检查事件。作为结果，“EA交易”在价格后拉动止损。
3.外部事件。虽然此类事件通常不会出现在纯粹的“EA交易”系统中，但通常而言，在作出决策时需要将其考虑在内。这包括调整订单、持仓，处理交易错误、图表事件（移动/创建/删除对象、按下按钮等）。一般来说，这些是无法在历史数据中验证且仅在“EA交易”工作时出现的事件。
此类“EA交易”的一个突出示例是带图形交易控制的交易信息系统。
各种“EA交易”都是基于这三种事件源的组合。
“EA交易”的工作是什么？MQL程序交互的基本框架如下图所示。
然后程序执行第二个程序块-处理订单和持仓的模块，此时事件处理程序块从模块中调用。每个模块仅可查询与其相关的事件。
该序列可称之为带直接逻辑的框架，因其首先确定“EA交易”将要做什么（使用哪些事件处理模块），然后它才实施如何以及为什么要做（获取事件信号）。
直接逻辑和我们对世界的认知以及泛逻辑一致。毕竟，我们首先是思考具体概念，接下来才能对其进行终结，然后是将它们分类以及识别它们的相互关系。
设计“EA交易”在这方面也不例外。首先是声明“EA交易”应该做什么（开仓和平仓、拉动保护止损），然后才是指定在哪个事件中以及如何去做。但在任何情形下反过来都不成立：接收信号然后思考在何处以及如何处理。这是反向逻辑，最好不要使用，否则您将会获得冗长的代码和大量的条件分支。
下面是一个关于反向逻辑和直接逻辑的示例。通过RSI信号开仓/平仓。
在反向逻辑中，“EA交易”首先是获得指标值，然后检查信号方向以及您需要对持仓执行的操作：买入开仓和卖出平仓，或反之亦然-卖出开仓和买入平仓。也就是说，切入点为获取和分析信号。
在直接逻辑中，一切都是相反的。“EA交易”具有开仓和平仓两个模块，它只需检查执行这些模块的条件。换言之，在进入开仓模块后，“EA交易”接收指标值并检查其是否是开仓的信号。然后，在进入平仓模块后，“EA交易”检查其是否是平仓的信号。也就是说，不存在切入点-系统状态分析具有独立的工作模块（设计的第一个原则）。
建议：说明交易系统时，请勿以“1.获取信号...开仓订单”诸如此类的话语开始，而是立即划分出几个部分：“a)开仓订单的条件，b)维护订单的条件，等等。”，然后分别分析所需的信号。
要更好地理解这一方法，下图给出了以四种不同的“EA交易”为上下文的不同工作框架。
a).“EA交易”，仅基于某些指标的信号。它能够在信号改变时开仓或平仓。示例-MA“EA交易”。
c).基于指标的“EA交易”，但添加了追踪止损和操作时间。示例-在开立持仓通过MA指标进入趋势时利用消息套利。
d).“EA交易”无指标，带平均持仓。它仅在建立新柱时对持仓参数进行一次验证。示例-平均“EA交易”。
从框架中我们可以看出，使用直接逻辑说明任何交易系统都是极其简单的。
使用上文提到的所有原则和要求创建一个类，这将成为未来所有“EA交易”的基础。
该类的所有函数可分为三组。嵌套函数的基本框架以及函数的说明如下所示。
该小组函数是使用订单类型、交易品种参数和价格值设置订单（未结订单和止损订单）的基础。这些宏函数体现了第二个设计原则-抽象化。它们在“EA交易”使用的交易品种上下文中工作。