Editorials

Benefits of Domain Model Driven Design

by Ben Taylor

An Online Conference with REAL Technical Sessions?
You bet. Check out the SSWUG.ORG Virtual Conference – more than 30 sessions from top MVP speakers, talking about real-world solutions. Get more information here… time is running out to register, and you get a DVD *and* a SSWUG membership with your registration. You can’t go wrong. Check out the site for more info.

>> Read more here

Benefits of Domain Model Driven Design
When using Model Driven Design (MDD, see the editorial for a description) the developer builds objects designed to solve the application requirements ignoring any form of persistence. In doing so the application can be built and tested long before any database or other form of persistence is designed or implemented. The Model becomes the contract to which the persistence layer must adhere.

Later, when implementing persistence, the persistence layer becomes responsible for any dissonance between the application model interface and the persistence interface. Using Object Oriented data stores, you may be able to simply use your Application Model as the objects persisted. This is something that NoSQL data stores such as MongoDB, Cassandra, and even BigTable support easily. I have seen Cache used in this environment effectively as well. There are LOTS of other persistence engines for object storage that are emerging today.

Many times we choose a relational data store for our persistence. SQL Engines are the most common relational data storage in use today. However, there is dissonance between objects and relational tables where there is often no 1 to 1 relationship between objects and tables. In this case some pattern is used to convert objects to and from tables, or even SQL

In the Dot Net world, nHibernate is one of the most mature frameworks for implementing a Model -Driven Persistence to an SQL relational database. The latest release of Entity Framework from Microsoft now also supports Model First development and mapping between objects and tables.

Here are some questions you might ask when deciding if Model Driven Development best fits your needs.

  • Do I need to persist my application data to different data schemas?
  • Do I need to develop my application out of synch with the Database development schedule?
  • Do I need to be able to substitute persistence frameworks easily at a later time?
  • Do I need to shard my data into multiple data stores?
  • Do you anticipate Business Objects/Processes that do not map readily to relational data models?

Write to btaylor@sswug.org with your experiences related to Model Driven Design. Perhaps you have suggestions for tools, frameworks, processes or even questions to determine if Model Driven Development is right for you.

Cheers,

Ben

Featured White Paper(s)
NobHill SOFTWARE Database Compare Product Look
read more)

Featured Script
dba3_fx_CalendarExclusionsFixedDatesForRange_Article
Modeling Date Logic III: Implementing Business Calendars (by example in MS Sql Server 2000) http://bitonthewire.wpengine.com/see/17379 De… (read more)

Tags:
Author: Ben TaylorBen is a Relational Database veteran starting in the early eighties on DEC Vax database systems such as Bloom and Harvest. He has specialized in SQL engines for more than two decades, with a primary focus on Microsoft SQL Server. Ben has worked with small and large databases for both OLAP and OLTP working on systems for many industries such as Medical (Medical Claims and Eligibility Warehouse, HMO Provider Management, Enrollment), Financial (credit card processing, mortgage, stock portfolio management), Manufacturing (Assembly Line and Product Assemblies), Sales, Auto Auctions and more.