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
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
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