Re: Object Domain

I agree with David's statement below, generally. It's worth noting that in Smalltalk, our object memory +
virtual machine together serve as a kind of non-relational database which preserves both state and
behavior, but one doesn't generally have to think about it and that's beautiful:)

Even in SQL one has triggers and stored procedures, so perhaps the distinction is pervasively arbitrary.
Someday we may have fast non-volatile RAM and no separate long term storage, at which point databases and
persistence as we popularly think about them may even disappear entirely.

One of Smalltalk's offspring, the Self language, uses message sends (as far as the programmer is
concerned) to access state, and thus does away with assignment in the usual/low-level sense. This is fun
to think about (for me anyway!) 

Someone please correct me if I'm wrong here, but I think of "object domain" and "object model" (where the
word model is distinct from and more general than the Model in MVC) as being interchangeable. 

I think of an object domain as just the set of objects which implements a feature or solves a problem. I
suppose I may have my terminology mixed up though, so sound off if I'm wrong here folks:) 

--Casey Ransberger

On Jul 6, 2012, at 2:42 PM, David Mitchell <david.mitchell <at> gmail.com> wrote:

> I think a lot of people think of the domain as the database, but I've always thought of the database as how you
store your domain model, not the domain model itself.