Depending of the technology used there is different approach to this task. The domain object model at the enterprise level will represent a complex data model a rule architect does not want to expose as-is to the rule engine and the rule authoring environment. Navigating a complex graph of objects will bring unnecessary complexity for the rule writer. So we recommend to always try to use a view of the enterprise domain object model. For example in Financial Industry the business domain data model defined in MISMO (www.mismo.org), brings a lot of value for an enterprise willing to define a common ontology for their data models. But exposing the MISMO model as it is within a BRMS rule authoring IDE will put too much complexity. As the Architect is responsible to design decision service reusable cross application, it may make sense to consider view of this object model in the context of the service.

For the application the view can be defined in two entities:

• the Domain Object Model using java or xml schema as the underling technology
• or out of the box object view, like ILOG-Business Object Model element. The BOM is mandatory to write rule on, but it can be created from an existing java model or XSD or created top-down.

If the model does not exist in the application, or at the enterprise level we still recommend to develop the domain model, using an UML designer and code generation tools.

It is also important to consider designing a java model or XSD schema which is closed to the business concepts used by the rule but built as a view of the domain object model (We called that the Rule Business Object Pattern or RBO): in the example of standard object model like MISMO or ACORD, it makes sense to do not expose all the class definition, attributes and enumerated to avoid exposing a complex rule language to the business user. This view will be instantiated by the application business logic in the context of preparing the data for the rule services

When designing a Domain Object model one of the challenges is to determine what should be an entity and what should be an attribute of the entity.  This is why knowledge engineers like the Enterprise Ontology as a start point for developing these concepts.  The Enterprise Ontology describes the major entities and concepts that apply to all enterprises and it provides a very good starting point for the establishment of static object models and data models.

The difference between a class and an entity type is that classes have both data and behaviors whereas entity types just have data. A normal entity depicts one concept.

Use multiple different UML class diagram to represent entities and their relations. Then enhance them to have a complete class diagram from which you should be able to generate java code or XSD.

Capture Meta data about each entity: business name, business definition, super type or subtype, number of occurrences, primary key, and alternate keys.

It is possible to consider designing a Domain Model using Interface, and then apply different type of implementation according to different execution pattern or platforms. For example we can design a;

• Staged deployment with different execution classes
• Dynamic model (XML based or dynamic classes) versus static model
• Production/test models (active objects versus mock objects)