1、 减少代码冗余和代码量：
最常见也是最有效的方式是使用代码生成来达到目的。而在 OFBiz 中，使用动态 API 来达到这一目的。包括 Entity、Service、Workflow、Rule Engine 以及 MiniLang。这些动态 API 都基于配置和定义文件来进行简单的操作。这与代码生成有异曲同工之妙。不用更改代码，而只需要修改配置文件，就可以适应需求的变化。
2、数据层：
最佳实用工具是使用OFBiz Entity Engine。对于大多数应用，实体引擎能够很优雅的处理 99% 的数据库操作。在一些比较少的情况下，实体引擎的效率不是很高，因此我推荐使用 JDBC 代码来进行查询。
在使用实体引擎的时候，实体和域的名字都使用inline strings。这使得代码的阅读和维护都更加容易。如果你需要准备一个大的 Map 或者 EntityCondition? 传递到 EE (Engine)方法中，一般另外起一行，看起来更加清晰些。或者在调用 EE 方法前的其他行当中。
使用一个简单、标准化的数据模型。通常数据模型可以直接从需求中提取出来。通常的结果是一个高度标准化的数据模型，这使得你的生活更加轻松。当你需要把数据绑定起来做报表，使用 View-Entity (试图实体)特性来实现 join 和grouping 以及summarizing 等操作。
总是使用 Primary Keys。当存在更具描述性的组合主键时，避免使用自动生成的单一主键。总是使用 relationship definition 来描述实体是如何被一起使用的，这样不仅更加容易获得相关数据，而且还可以对外键进行约束，通过自动的基于外键的索引来提高性能。
3、逻辑层：
调用逻辑最好的工具就是 OFBiz Service Engine。几乎所有的商业逻辑都应该当做服务来被实现。这样可以提高可用性，使得基于组件的开发更加容易。
虽然服务比较灵活，当然也有某些时候服务模型并不适合的地方，甚至商业逻辑也不适合。在某些时候，直接调用一个script 或者Java 方法是有必要的，并且在这些情况下，服务模型没有什么意义，也不应该被使用(应该是从商务逻辑方面考虑服务没有意义)。
服务引擎提供很多的方式来将逻辑的实现或者商业逻辑当做服务，从而减少代码量。你可以同步调用、异步调用或者是按照 Schedule 调用你的逻辑。当你调用某个服务时，你不需要知道它在什么位置，以及它时怎么实现的。这使得使用远程服务和不同语言实现的服务更加容易，且更有效率。通过 服务引擎来透明的访问不同语言实现的逻辑，对于有效地某些特殊语言来说是非常重要的。
在定义服务时，应该尽量使得它们简单。任何时候，如果一个服务是基于某个实体的话，确保是使用自动 attributes tag 来从实体域的定义中创建 attributes。另外，不是使用 attribute tag来重新定义 attribute，而是只使用 overrid tag 来描述那些你想改变的信息。
总是用最简单和最恰当的语言或工具来实现你的服务。你可以使用很多种语言来实现服务，例如：Java，BeanShell或者任何其他 BSF 兼容的 Script 语言（如Jython，Jacl，JavaScritp，等等），（译注：不知道Groovy行不行），OFBiz工作流引擎的处理器，OFBiz MiniLang? 的 Simple-methods，以及其他各种语言。附加的语言很容易被支持，只要写个简单的 Adapter 就行。
总是通过服务引擎来调用远程的逻辑。你可以通过多种机制来调用远程服务，包括 HTTP，SOAP， JMS 和其他方式。你可以很容易的增加远程服务调用机制，只需要写个简单的 Adapter 就行。
在大多数情况下，你愿意使用服务引擎来把你的服务调用自动的 wrap 到一个事务当中，这样整个操作都是原子性的，或者都成功，或者都失败。注意如果你在一个已经存在的事务当中调用某个服务，它将会自动识别这个事务，并且使用这个事务，而不是另外创建一个新的事务。
4、表现层：
总是将输入的处理逻辑，准备视图数据的逻辑和视图表现的模板分开。这使得不仅能够在 Web 应用当中容易重用这些逻辑，而且也可以在胖客户端应用中容易的重用。这使得你的代码更容易组织，也更容易在调试过程中找到特定功能的代码，更易于阅读。
对于这三个分开的逻辑，下面我们单独进行讨论。
1、输入处理逻辑
输入处理逻辑总是应该与 controller.xml 文件中定义的请求联系在一起，而不是和视图绑定在一起。输入处理逻辑通常被当做一个服务来实现，并且通过服务的事件处理来被调用，这个事件处理机制会自动的将请求参数中的数据或属性传递给服务， 并且将它们从 String 转换为服务定义中定义的 object 类型。这样，在描述所关心的参数时，更加容易，只需要使用服务定义，并且由这个框架为你准备其他的东西。
当然，在不少情况下， 输入处理逻辑不能被实现为服务。对于与请求相关的逻辑而言，存在着很多其他的事件处理机制来使得你对请求的上下文有更多的了解。一个例子就是文件上传，另外一个例子就是在服务处理之前进行特别的预处理和参数的验证。注意你可以在这些自定义的事件处理当中调用服务，而且在可能的情况下，通常的逻辑总是应该被实现为服务的。
总是让Control Servlet 的配置来决定针对某个请求的事件，由哪个request handler 来响应。在大多数情况下，响应通常是用来生成视图，但是有时也会用请求处理链来获得逻辑重用和更高级的流控制。
2. 视图数据准备逻辑
视图数据准备逻辑总是和它所准备的视图模板联系在一起。这应该通过 JPublish 的页面定义xml文件中的 action 来描述(可能是以前版本，现在使用独立的Widget)。当一个页面被分解为多个模板时，这个数据准备动作应该被联系到每个独立的小模板上，并且为它们准备数据。这使得模板和内容片 (content pieces)的在多个页面中的重用和移动变得更容易。
视图数据准备逻辑应该用动态script 语言实现，如 JavaScript, BeanShell?, Jython 或者时 Jacl，使得用户界面上修改起来更容易。通常的数据获取被实现为服务，而这些动态的 script 则可以调用这些服务。这使得这些功能更容易共享和重用。
当准备数据时，你可以将数据对象放在 context 对象当中，使得视图模板能够获取到这些对象。context对象的所有属性都能够被模板获取到，只要模板语言支持它。
注 意，当使用jsp做为视图模板时，你不能使用 JPublish，所以 action facility就没法使用。我们对于JSP的建议是，在页面顶端使用一个单一的 scriptlet 来准备数据。在这种情况下，调用 worker 服务或是worker Java 方法来做大部分的工作，并且使得页面包含尽可能少的逻辑。
3. 视图表示模板
用来生成 HTML 和其他文本的最好的template engine 是 FreeMarker。它类似于 jakarta 的 Velocity，但是更由弹性，并且和 OFBiz 核心框架的其他工具结合的更好。我们强烈推荐使用 JPublish 而不是直接运行 FreeMarker? 模板，这样actions可以与页面和模板联系起来，页面也可以用普通模板进行修饰。下面我们将描述如何最好的使用它们：
视图表示模板应该被保持尽量的简单，一般的信息如header, footer, sidebars 等应该在运行期使用 decoration 模式组合起来。用于修饰的模板文件在 JPublish 的定义文件当中进行说明。
总是使用最适合你的视图生成工具。FreeMarker 是强烈推荐的用于生成文本的工具，但是在某些情况下，其他工具也许更适合。当你想显示报表的时候，我们推荐使用 Jasper Reports 或者是 DataVision。并且通过一个 controller.xml 中的 view-map 将这些报表组合起来。如果你想用其他 text 生成工具如 velocity 或者 XSLT，我们建议你通过JPublish 来使用，特别是当你想修饰它们并且有 actions 为这些模板准备数据时。
如果你有经常被重复使用的 UI 模式，例如 forms, 查询数据显示，tab 或者是菜单，可扩展的树状视图，目前我们建议你使用 XML 文件来描述这些 UI 模式，然后通过一个 rendering 引擎、或者是 XSLT/FreeMarker等工具来转换为 HTML 或者其他输出。
对于大多数 form, 表现他们的最好办法是通过 OFBiz Form Widget，它可以接受一个 XML 的定义文件，支持多种 UI 类型，并且使用已有的 OFBiz 代码如服务和实体定义等。这样的代码量更小，而且更容易维护。
当无法使用 FreeMarker时，我们推荐使用其他动态模板语言如Velocity。当这个也无法使用时，我们推荐使用 JSP。但是，注意使用 JSP 时你无法利用 action 或者是修饰模板，因为它不能在JPublish 下运行，这归功于JSP规范。虽然你不能使用修饰模板，但是你可以使用 OFBiz 的 Region 框架基础上的组合视图模式。Region 在 regions.xml 当中进行描述。注意这些不如 JPublish 的组合视图那么容易使用，而且他们不支持actions. 但是 Regions 框架确实提供了很多灵活性，在很多情况下都是非常有用的。
5、在开始之前——方法学方面的建议
在你开始创建任何东西之前，必须首先定义一些东西。任何细节必须在某个地方被决定。因为个体之间交流的困难性，以及牵涉到复杂系统所固有的困难，我们推荐以下一些实践：
虽然这些技术用在OFBiz 的某些核心功能组件当中，但是他们对于那些基于OFBiz创建软件的人来说也非常有意义。原因在于， OFBiz 是一个通用框架，是一些应用组件和软件的集合。在很多情况下，这些应用可以直接使用，但是他们不能满足任何人的任何需求。基于这些原因，用于满足特定领 域，特定类型的业务，和特定最终用户的产品，需要在 OFBiz 的基础上进行更多的工作。
方法学：保持简单，但是不要太简单
有无数的软件开发方法学存在着，而且随时都有新的方法学被介绍出来。在这些数以百计，甚至千计的关于不同方法学的文档当中，有非常多好的想法。通常我们推荐 "Agile" 方法，使得事情尽可能的简单，但是又不要太简单。更多的关于"Agile"开发方法，请参见 www.agilealliance.org
所以最大的问题是：什么是当前项目所需要处理的最小集合？越复杂的需求，你需要越多的时间和金钱。越轻量级的需求，你无法满足项目需要的风险越大。
最少的角色
对于任何项目来说，实际上只有两种角色：买家和卖家。对于软件项目或是所提供的服务，更常见的属于是客户和开发者。本文中将使用这两个术语。术语开发者在此 处用于泛指那些生产最终发布产品的人，而客户则泛指那些最终为产品支付的人。某些情况下，开发者和客户都是同一个人，或是同一组人。
此处应该指出，“客户”的一个重要部分是软件的真实使用者。可能的情况下，应该和这些用户进行user story 和 use cases的复查。
