Share via

Domain Modeling

  • Article

My focus within the Olso team is on domain modeling – creating models for specific problem domains using the Oslo modeling platform’s languages and tools.  Let me describe why we think of this as more than just data modeling.

At the center of an Oslo domain is a data model authored in M. The primary purpose of this model or schema is to describe repository storage, defined in terms of extents.  This domain schema defines data integrity constraints and may also define reusable data definitions or types, as well as computed values that describe interesting ways to retrieve and compute data from the model.  The schema is compiled into SQL, resulting in tables, views, constraints and functions which are loaded into a SQL Server database primed with some simple Repository patterns. The result is a simple and easy-to-query and otherwise normal SQL database, which can be queried using any SQL data access API or tools.

Surrounding this data model and considered part of the domain may be any number of domain specific languages, which if developed using Oslo may be textual, authored in MGrammar, or visual, authored with Quadrant.  These DSLs define ways in which domain information (instance data) can be created or presented.  Any number of textual and visual languages may be defined for the same domain, each customized to provide some specific perspective.  A domain can also reference other domains, so models and languages may also reference (and in due course, embed) other models and languages.

Accompanying each DSL may be utilities that map or import/export language 'documents' to and from repository storage. For textual DSLs described in MGrammar simple transformations can be expressed in the grammar itself - more complex transformations need to be described separately. A key Oslo scenario will involve cataloging and potentially creating/editing pre-defined artifacts that might otherwise be created and/or consumed externally by other tools.

Collectively, the domain schema, textual and visual DSLs, and their accompanying import/export tools define what we think of as a domain from an Oslo standpoint and will typically be evolved as a unit. This whole-domain perspective is an important part of the way we think about modeling with Oslo and strongly influences how you can expect the Oslo platform to be developed.

You can see some early examples of domain schemas included with the CTP on the Oslo Dev Center. Take a look if you can.

Next up, data modeling design patterns in M...

Comments