Comments on: Domain Drivel http://blog.springsource.com/arjen/archives/2006/10/10/domain-drivel/ A blog about programming in .NET and Java Mon, 19 May 2008 21:44:31 -0500 http://wordpress.org/?v=2.8.5 hourly 1 By: Stefan Tilkov's Random Stuff http://blog.springsource.com/arjen/archives/2006/10/10/domain-drivel/comment-page-1/#comment-1023 Stefan Tilkov's Random Stuff Wed, 25 Oct 2006 15:28:33 +0000 http://blog.springframework.com/arjen/archives/2006/10/10/domain-drivel/#comment-1023 <p><strong>BeJUG Enterprise SOA Conference</strong></p> <p>I gave a talk at yesterday’s Enterprise SOA Conference, organized by BeJUG (the Belgian Java User Group). It was a very nice event that gave me a chance to meet a bunch of interesting people from the SOA community; here is a short summary. (If yo...</p> BeJUG Enterprise SOA Conference

I gave a talk at yesterday’s Enterprise SOA Conference, organized by BeJUG (the Belgian Java User Group). It was a very nice event that gave me a chance to meet a bunch of interesting people from the SOA community; here is a short summary. (If yo…

]]> By: Claudio Perrone's Monologues http://blog.springsource.com/arjen/archives/2006/10/10/domain-drivel/comment-page-1/#comment-1020 Claudio Perrone's Monologues Sun, 22 Oct 2006 13:16:03 +0000 http://blog.springframework.com/arjen/archives/2006/10/10/domain-drivel/#comment-1020 <p><strong>Crested Butte - The Prologue</strong></p> Crested Butte – The Prologue

]]> By: David Levy http://blog.springsource.com/arjen/archives/2006/10/10/domain-drivel/comment-page-1/#comment-1018 David Levy Mon, 16 Oct 2006 01:03:13 +0000 http://blog.springframework.com/arjen/archives/2006/10/10/domain-drivel/#comment-1018 <p>I think there's a nice middle ground here: it's often not hard when designing a new application to ensure that the back end data is in a format which is not too domain dependent. Serializing objects into the database as bytes is probably one of the only things which will absolutely tie you to the language above. Anothing is having complex class hierarchies which should be minimized if possible (although not at a cost of having overly complex objects on top). As long as those two things are kept to a minimum, the backend should be fairly readily available for another application to plug on later or in tandem.</p> I think there’s a nice middle ground here: it’s often not hard when designing a new application to ensure that the back end data is in a format which is not too domain dependent. Serializing objects into the database as bytes is probably one of the only things which will absolutely tie you to the language above. Anothing is having complex class hierarchies which should be minimized if possible (although not at a cost of having overly complex objects on top). As long as those two things are kept to a minimum, the backend should be fairly readily available for another application to plug on later or in tandem.

]]> By: Luca Garulli http://blog.springsource.com/arjen/archives/2006/10/10/domain-drivel/comment-page-1/#comment-1016 Luca Garulli Fri, 13 Oct 2006 12:32:57 +0000 http://blog.springframework.com/arjen/archives/2006/10/10/domain-drivel/#comment-1016 <p>I think that a good OO model with a tool that "reads" your model and simplify your application development is the best!</p> <p>This is missed from IT industry! Why I should spend my resources to be puritan about my OO model and then convert it in DB and other?</p> <p>We need a tool that handle own OO model in all aspects: RomaFramework is an effort in this direction ;-)</p> <p>My 0,02</p> I think that a good OO model with a tool that “reads” your model and simplify your application development is the best!

This is missed from IT industry! Why I should spend my resources to be puritan about my OO model and then convert it in DB and other?

We need a tool that handle own OO model in all aspects: RomaFramework is an effort in this direction ;-)

My 0,02

]]> By: Geir http://blog.springsource.com/arjen/archives/2006/10/10/domain-drivel/comment-page-1/#comment-1015 Geir Thu, 12 Oct 2006 22:38:58 +0000 http://blog.springframework.com/arjen/archives/2006/10/10/domain-drivel/#comment-1015 <p>I agree with you conclusion, but I don't think your argument about domain models being less important because a relational schema has a longer shelf life than program code makes sense.</p> <p>Databases are used as business interfaces. Any published interface is going to be more stable than a (hopefully private) implementation of business rules. You will find the same issue in any published interface - it is going to be painful to change it, so you often don't.</p> <p>I also think Scott Ambler makes a lot of sense when he says that database design is lagging behind program design - database design tools lack any kind of sensible refactoring support. I have yet to meet a DBA with an active perception of how to go about refactoring a database model. This makes changing databases even harder.</p> I agree with you conclusion, but I don’t think your argument about domain models being less important because a relational schema has a longer shelf life than program code makes sense.

Databases are used as business interfaces. Any published interface is going to be more stable than a (hopefully private) implementation of business rules. You will find the same issue in any published interface – it is going to be painful to change it, so you often don’t.

I also think Scott Ambler makes a lot of sense when he says that database design is lagging behind program design – database design tools lack any kind of sensible refactoring support. I have yet to meet a DBA with an active perception of how to go about refactoring a database model. This makes changing databases even harder.

]]> By: EDef http://blog.springsource.com/arjen/archives/2006/10/10/domain-drivel/comment-page-1/#comment-1014 EDef Thu, 12 Oct 2006 19:57:48 +0000 http://blog.springframework.com/arjen/archives/2006/10/10/domain-drivel/#comment-1014 <p>Agree 100% ...Although you'll get no love from TSS and all the MFowler (or anyone else who thinks OO programming is the center of the software universe)... </p> <p>so many people get wrapped up in trying to provide n-levels of abstraction <em>cough</em>hibernate<em>cough</em> or software patterns that try to solve this inherent "impedence mismatch <em>cough</em>TableDataGateway<em>cough</em> that they forget that <B>the Data is King</B> not some ephemeral oo process that some website is trying to accomplish...(try working for a financial institution and you'd get that).</p> <p>The major things I see with Rich Domain is:</p> <p>1) Ok now I have a domain model with data AND logic... what if the logic is correct in one process/context (i.e. online OLTP order acceptance)... but Similar, yet not OK for another context (i.e. Auditing/ OLAP reporting)... </p> <p>2) Say I've persisted a version of my model many years ago, now I need to reconsititue it, but it fundimentally violates the validation rules in the Rich domain model... now what, do I need to keep multiple versions of the domain model handy, or have ways or relaxing constraints/logic?</p> <p>3 cheers for anemic domain!</p> <p>E.</p> Agree 100% …Although you’ll get no love from TSS and all the MFowler (or anyone else who thinks OO programming is the center of the software universe)…

so many people get wrapped up in trying to provide n-levels of abstraction coughhibernatecough or software patterns that try to solve this inherent “impedence mismatch coughTableDataGatewaycough that they forget that the Data is King not some ephemeral oo process that some website is trying to accomplish…(try working for a financial institution and you’d get that).

The major things I see with Rich Domain is:

1) Ok now I have a domain model with data AND logic… what if the logic is correct in one process/context (i.e. online OLTP order acceptance)… but Similar, yet not OK for another context (i.e. Auditing/ OLAP reporting)…

2) Say I’ve persisted a version of my model many years ago, now I need to reconsititue it, but it fundimentally violates the validation rules in the Rich domain model… now what, do I need to keep multiple versions of the domain model handy, or have ways or relaxing constraints/logic?

3 cheers for anemic domain!

E.

]]>