业务对象（Business Object）是由第三方开发的，在GeneXus 社区内可获得的知识对象。用其可以在一个应用中自动的加入一个特定的功能来获得增值效应。使知识重用变为可能。比如，如果你要开发一个包含多货币处理的应用，你可以选择使用一个已经开发完成的，包含所有多货币处理功能的业务对象来开始你的开发。使您的开发工作极大的减少。 Remote Data Service 提供默认的中间层业务对象 RDSServer.DataFactory，用于接收客户端请求并提供对指定数据源的读写访问，但不包含任何验证或业务规则逻辑。
用户可以创建能够提供与 RDSServer.DataFactory 功能相同的自定义业务对象，并且对应用程序的业务规则进行封装。
⒈由状态和行为组成
⒉表达了来自业务域的一个人，地点，事物或概念
⒊可以重用
1.实体业务对象：
表达了一个人，地点，事物或者概念.根据业务中的名词从业务域中提取的.如客户，订单，物品.在EJB应用程序中，一般为实体Bean.在传统的web应用程序中，可能是包含业务应用的状态和行为的普通javabean.
2.过程业务对象：
表达应用程序中业务处理过程或者工作流程任务.通常依赖于实体业务对象，是业务的动词.在EJB应用程序中，通常是模型的会话bean，或者消息驱动bean.在非EJB应用中，可能是javabean，包含特定的行为，作为应用程序的管理者或者控制者.
3.事件业务对象：
表达应用程序中由于系统的一些操作造成或产生的一些事件.
业务对象的抽象和整合有何联系呢，或许有人会问我这样的一个问题（以前的我也老想着这个问题），就这个问题我个人觉得，如果脱离业务抽象而想象一个架构体系，那么是一个本末倒置的愚蠢的做法，因为只有做了一个业务的抽象才能根本上满足需求本质，这样才能更实际的充分的得到现实业务现象的抽象才能合理有效的模拟实现的IT系统（一个IT化的过程第一步骤）。
整合IT系统面临一个很大问题如何抽象IT系统的交互问题，这个方面IBM采取了消息通信的抽象；它这样做当然有他的道理（也是比较接近现实场景的），但是我在这里顺便提一下我个人的想法，消息其实只是通信和协调的一个实现而已，但是还没有到本质；本质就是通信的协议的定制。我自己采取的就是在底层使用一个会话协议抽象（工作的保密关系不能再细说了，但是我的实践告诉我这样做有很高的架构体系扩展上，大家有机会可以试一试）。
所以业务抽象十分重要，只有把握好这一点，你的架构系统将体现更高的架构体系高度。你会发现需求的现象的本质，已经没有太多的需求变动能破坏你的架构还没有把握业务的本质）。