Bucking Conventional Wisdom
When you are at a place where a domain-model
(business-object-model) would be useful, what do you do? Do you
create a domain-model and use it? Or do you, like so many in our
industry, write code that processes relational objects
that hold onto just-enough tabular data needed to fulfill the request
and expose your business logic in procedural manner within your
servlet or EJB or JMS processes?
What if you were able to have direct access to a fully
constituted domain-model that understands how to do work required and
it automatically keeps track of and stores any related dirty-state in
a transactional-safe manner? Where your domain-model actually
and simply reflects the business and not some tabular representation
of your business-data. Such that when the business changes the
corresponding change to make in your system software is obvious.
If this promise of domain-driven-design as enabled through Facets is
of interest then you are encouraged to read the following articles
and papers.
The tendency of either not having a domain-model or
contaminating the domain-model due to the underlying data store is
addressed in this series of articles entitled Making
The Switch to Facets from an RDBMS.
If you are interested in understanding
what constitutes a well defined, well constructed and complete
domain-model and how that relates to Facets, then you will find this
page that discusses Domain
Driven Design to be useful.
After reading these documents, one should be able to
understand the unnecessary overhead incurred due to relational
technology and that there is a product offering that simultaneously
eliminates an entire layer of the J2EE architecture as unnecessary,
the O/R Mapping layer and its corresponding goo, and enables the
appropriate and full development of domain-models that fully reflect
and serve the business, especially in today's SOA-world of Web
Services.
