Arjen Poutsma: Domain Drivel

Discussions

News: Arjen Poutsma: Domain Drivel

  1. Arjen Poutsma: Domain Drivel (51 messages)

    Arjen Poutsma, in "Domain Drivel," suggests that rich domain models may not be all they're cracked up to be - that "it is not a silver bullet. Use it when it gives an advantage, but don’t swear by it." Considering that most of us store data via a relational database - which forces an anemic model - it's good to keep this in mind.
    Recently, though the influence of books like Domain Driven Design, it has become fashionable to think that a rich Domain Model is one of the most important things there is. Well, that might be the case for you as an OO developer, but for the Enterprise the database is much more important. It is not without reason that a large number of databases outlive the applications built around them. And for the user of your Web application the most important part is the HTML UI he or she is looking at. Finally, in this SOA day and age, the OO business logic is probably not the only business logic that is there. Your application is part of a team of services, the business logic on the mainframe is just as important! Now, I'm not saying that a rich domain model is not important. I'm just saying that — as with any solution — it is not a silver bullet. Use it when it gives an advantage, but don’t swear by it. In the grand scheme of things, your precious OO model is not as important as you think it is.

    Threaded Messages (51)

  2. Re: Arjen Poutsma: Domain Drivel[ Go to top ]

    Arjen Poutsma, in "Domain Drivel," suggests that rich domain models may not be all they're cracked up to be - that "it is not a silver bullet. Use it when it gives an advantage, but don’t swear by it." Considering that most of us store data via a relational database - which forces an anemic model - it's good to keep this in mind.
    What? It doesn't matter where you persist your state, be it a relational db, or some in memory database, it's just state persistence. Objects are about operations on its state, so this statement makes absolutely no sense, or maybe it was mistated. When all your doing is sending state around from one service to another, then yes, some transaction script would do rather than a rich domain model, but to imply that persisting object's state in a relational store forces us to use an anemic model is utter nonsense.
    Recently, though the influence of books like Domain Driven Design, it has become fashionable to think that a rich Domain Model is one of the most important things there is.
    Fashionable? So since the release of GoF book it has become fashionable to find generic solutions to common problems? The book didn't make anything fashionable, it merely documented what many have discovered a long time ago, as did the GoF book.
    Well, that might be the case for you as an OO developer, but for the Enterprise the database is much more important. It is not without reason that a large number of databases outlive the applications built around them.
    This has nothing to do with trying to build maintainable, extensible, scalable OO applications. Of course data will outlive the business process, since business processes change and/or go away, the data will be used later for various purposes.
    And for the user of your Web application the most important part is the HTML UI he or she is looking at.
    Ok? That's because they are not the folks maintaining and extending the apps behind the scenes as requirements change. You can put together a HTML UI app using a single perl CGI script that has states and functions that operate on that state. The script will run about 10000 lines, but to the user, it will all look the same. I don't get the point.
    Finally, in this SOA day and age, the OO business logic is probably not the only business logic that is there.
    Finally something that makes sense. Yes, in the SOA world, a business process app might be just an aggregation of loosely coupled services from various endpoints that can either be brought together within some BPM app, a home build app, or possibly processed in a proceedural way, though depends on the application requirements, size, etc... The services within the applications that you expose, are actually use cases encapsulated behind a service interface, exposes as a web service endpoint. The service call itself encapsulates the access to the domain model, which is the application logic that is used to provide the service. Of course that depends on whether you're building an enterprise applications, or simply some play around program like TaDa lists:-) Sorry, had to plug this in.
    Your application is part of a team of services, the business logic on the mainframe is just as important!

    Now, I'm not saying that a rich domain model is not important. I'm just saying that — as with any solution — it is not a silver bullet. Use it when it gives an advantage, but don’t swear by it. In the grand scheme of things, your precious OO model is not as important as you think it is.
    Ok, man, what ever you say:-) Ilya
  3. Re: Arjen Poutsma: Domain Drivel[ Go to top ]

    Recently, though the influence of books like Domain Driven Design, it has become fashionable to think that a rich Domain Model is one of the most important things there is. Well, that might be the case for you as an OO developer, but for the Enterprise the database is much more important. It is not without reason that a large number of databases outlive the applications built around them.
    The foremost reason a database outlives an application is that it is too expensive to migrate the database. For the rest of the article I can only say that I use domain models but I use them practically meaning: my database schema is also very important I compromise on both sides and keep it all pragmatic.
  4. Re: Arjen Poutsma: Domain Drivel[ Go to top ]

    The foremost reason a database outlives an application is that it is too expensive to migrate the database.
    To where will you migrate the 'data' from 'database' - XML/BLOB/Flat Files/Enterprise Hashmap/... Databases are there to manage data. We code to perform a some business fuction - which necessarily consume/produce data. It is not just the expense that results in data outliving applications. I have seen and continue to see database migrations - painful as they are. But the data migrates to another database. To think that use of database forces anemic model is, well, anemic.
  5. Ivo, what did you smoke?[ Go to top ]

    Ivo, Go and do a second reading of the article and come back with something sensible, ok? Jan
  6. whatever.[ Go to top ]

    Arjen Poutsma, in "Domain Drivel," suggests that rich domain models may not be all they're cracked up to be - that "it is not a silver bullet. Use it when it gives an advantage, but don’t swear by it." Considering that most of us store data via a relational database - which forces an anemic model - it's good to keep this in mind.
    Recently, though the influence of books like Domain Driven Design, it has become fashionable to think that a rich Domain Model is one of the most important things there is. Well, that might be the case for you as an OO developer, but for the Enterprise the database is much more important. It is not without reason that a large number of databases outlive the applications built around them. And for the user of your Web application the most important part is the HTML UI he or she is looking at. Finally, in this SOA day and age, the OO business logic is probably not the only business logic that is there. Your application is part of a team of services, the business logic on the mainframe is just as important!

    Now, I'm not saying that a rich domain model is not important. I'm just saying that — as with any solution — it is not a silver bullet. Use it when it gives an advantage, but don’t swear by it. In the grand scheme of things, your precious OO model is not as important as you think it is.
    "which forces an anemic model"??? What a load of crap. I have spent more than half of my career fixing other people's code that use this same idea. Good OO makes code robust and maintainable. If you don't understand how to use OO, please get out of the business.
  7. Re: whatever.[ Go to top ]

    I have spent more than half of my career fixing other people's code that use this same idea. Good OO makes code robust and maintainable. If you don't understand how to use OO, please get out of the business.
    Java monkeys who think OO is a silver bullet should be getting out of the business or resigning themselves to becoming maintenance blubs.
  8. Re: whatever.[ Go to top ]

    I have spent more than half of my career fixing other people's code that use this same idea. Good OO makes code robust and maintainable. If you don't understand how to use OO, please get out of the business.


    Java monkeys who think OO is a silver bullet should be getting out of the business or resigning themselves to becoming maintenance blubs.
    I was hoping you were being sarcastic, but since we all know how much you like Java... Java is a tool to accomplish OO design, not the other way around. OO can be accomplished with Java, but can also not be accomplished. There are masses of Java developers who think they program OO just because they create classes and encapsulate the state and later expose it through some getter. Their domain logic is scattered beyound belief, etc... Though I'm not a big fan of Ruby as an enterprise app development platform, though the language itself seems quite nice, you can accomplish good OO with Ruby, Python, etc... as well. OO is a silver bullet, for pretty much all but non-trivial apps. Ilya
  9. Re: whatever.[ Go to top ]

    Though I'm not a big fan of Ruby as an enterprise app development platform, though the language itself seems quite nice, you can accomplish good OO with Ruby, Python, etc... as well. OO is a silver bullet, for pretty much all but non-trivial apps.
    You're right, OO is a silver bullet when it's real OO and not brain-dead Java OO.
  10. Re: whatever.[ Go to top ]

    Though I'm not a big fan of Ruby as an enterprise app development platform, though the language itself seems quite nice, you can accomplish good OO with Ruby, Python, etc... as well. OO is a silver bullet, for pretty much all but non-trivial apps.


    You're right, OO is a silver bullet when it's real OO and not brain-dead Java OO.
    Common Frank, you can have brain-dead Ruby OO, Python OO, etc... Actually I'd argue that the expressiveness of Ruby would make it alot easier for a non-knowledgable developer to create brain-dead OO and even proceedural apps. Though many argue about some language semantics of java, etc..., it was designed that way for a reason and is highly appreciated within large application development environments. This whole thing with Perl (I actually used to be a big fan of it) "There is more than one way to do it", is complete garbage, at least I realized it when trying to read other people's stuff and applications that have numerous developers on it that choose to express themselves in 50 different ways. Consistency is a must in large apps. Ilya
  11. Re: whatever.[ Go to top ]

    What's up with Java monkeys and Ruby? You criticize Java and they think David Hansen Hasselhoff (WhateverTF RoR boy's name is) personally insulted them. If you want to start comparisons, compare to Scala or Nemerle for a real comparison, especially Nemerle, which shows what you can really do on top of a common runtime.
  12. Re: whatever.[ Go to top ]

    What's up with Java monkeys and Ruby? You criticize Java and they think David Hansen Hasselhoff (WhateverTF RoR boy's name is) personally insulted them.

    If you want to start comparisons, compare to Scala or Nemerle for a real comparison, especially Nemerle, which shows what you can really do on top of a common runtime.
    Hi Frank, Thanks for the link to Nemerle. Have you been using it in more than in sample applications ? Any chance to see a port to the JVM ? Christian
  13. Re: whatever.[ Go to top ]

    Though I'm not a big fan of Ruby as an enterprise app development platform, though the language itself seems quite nice, you can accomplish good OO with Ruby, Python, etc... as well. OO is a silver bullet, for pretty much all but non-trivial apps.


    You're right, OO is a silver bullet when it's real OO and not brain-dead Java OO.
    There is no silver bullet.
  14. Re: whatever.[ Go to top ]

    There is no silver bullet.
    I completely agree, but at the moment, OO (read: usage of a domain model) is the closest we can get :-)
  15. Re: whatever.[ Go to top ]

    Though I'm not a big fan of Ruby as an enterprise app development platform, though the language itself seems quite nice, you can accomplish good OO with Ruby, Python, etc... as well. OO is a silver bullet, for pretty much all but non-trivial apps.


    You're right, OO is a silver bullet when it's real OO and not brain-dead Java OO.
    Frank, I wish I could meet you in person. At my last gig I completed a project that was estimated to take 6 months in less than 2 months. The app is incredibly easy to maintain and add on new functionality. It all happened because I am really good with Java OO. BTW, I'm on track to gross $200,000 this year and I don't even like IT. Dig it.
  16. Re: whatever.[ Go to top ]

    Sure "Race Condition", with your mad skillz it should've taken you a week and you should be grossing over a million this year.
  17. Re: whatever.[ Go to top ]

    "Race Condition", it sounds to me you're in a race condition with yourself. I just wish you'd get a deadlock and shut it. It makes no difference how much money you make this year, last year, or next year... but based on your communication "skills", I wouldn't even pay you a dime... no matter how "expert" you think you are. And just for the record... I happen to know Arjen, and I can only wish you to be as good OOPer as him.
  18. Re: whatever.[ Go to top ]

    "Race Condition", it sounds to me you're in a race condition with yourself. I just wish you'd get a deadlock and shut it. It makes no difference how much money you make this year, last year, or next year... but based on your communication "skills", I wouldn't even pay you a dime... no matter how "expert" you think you are. And just for the record... I happen to know Arjen, and I can only wish you to be as good OOPer as him.
    I'm sorry. Peace.
  19. Re: whatever.[ Go to top ]

    "Race Condition", it sounds to me you're in a race condition with yourself. I just wish you'd get a deadlock and shut it. It makes no difference how much money you make this year, last year, or next year... but based on your communication "skills", I wouldn't even pay you a dime... no matter how "expert" you think you are. And just for the record... I happen to know Arjen, and I can only wish you to be as good OOPer as him.
    No one is saying that Arjen is not a good OO programmer. But his article makes absolute no sense. To make a relation between whether your data is persisted and whether you have a rich domain model is absurd. The entities which are persisted are anemic because of the people that design them. In reality, you should create your domain model and then annotate/configure it for persistence, not the other way around. Ilya
  20. Re: whatever.[ Go to top ]

    To make a relation between whether your data is persisted and whether you have a rich domain model is absurd.

    The entities which are persisted are anemic because of the people that design them. In reality, you should create your domain model and then annotate/configure it for persistence, not the other way around.

    Ilya
    I think the point that Arjen was trying to make is that sometimes you have to start from a relational model. You can't always design the domain model first and *then* think of persistence. Mind you, this is not an edge case. Virtually all reporting applications of scale need to start with schema design. There is simply no business logic that would make sense to put in Java (or Ruby or whatever)--all possible operations are expressed in the schema and SQL queries. Hence an anemic domain.
  21. Re: whatever.[ Go to top ]

    To make a relation between whether your data is persisted and whether you have a rich domain model is absurd.

    The entities which are persisted are anemic because of the people that design them. In reality, you should create your domain model and then annotate/configure it for persistence, not the other way around.

    Ilya


    I think the point that Arjen was trying to make is that sometimes you have to start from a relational model. You can't always design the domain model first and *then* think of persistence. Mind you, this is not an edge case. Virtually all reporting applications of scale need to start with schema design. There is simply no business logic that would make sense to put in Java (or Ruby or whatever)--all possible operations are expressed in the schema and SQL queries. Hence an anemic domain.
    Patrick, I don't disagree if this is what was meant. I do disagree with starting with the relational model and here is why. Most reporting applications are there to report on data that is collected through some business process application(s). The data within the store which the reporting app connects to, is there as a persistent state of some application(s), therefore it wouldn't be very wise to design around the limitations that the relational, hierarchical, or any other model puts on the design of an OO app. The use case where I'd agree with you on, is if you have some data warehouse, or some database that collects data by synching with other data sources, for reporting purposes. In these cases, if you're writting an inhouse reporting app, there is still a lot to design and though the logic might lie in SQL and stored procs, there is a whole domain model build around how to construct criterias, user preferences, supporting use cases, etc... Basically there is still a domain model at hand, unless your application consists of simply providing a text box to enter a SQL query, which is then executed and teh result set transformed into some visual input. But for the most part, there are reporting apps out there to do such things that you won't have to write anything at all. Ilya
  22. Re: whatever.[ Go to top ]

    I think the point that Arjen was trying to make is that sometimes you have to start from a relational model. You can't always design the domain model first and *then* think of persistence. Mind you, this is not an edge case.
    Exactly, that is true from my expericence.
  23. Re: whatever.[ Go to top ]

    I think the point that Arjen was trying to make is that sometimes you have to start from a relational model. You can't always design the domain model first and *then* think of persistence. Mind you, this is not an edge case. Virtually all reporting applications of scale need to start with schema design. There is simply no business logic that would make sense to put in Java (or Ruby or whatever)--all possible operations are expressed in the schema and SQL queries. Hence an anemic domain.
    Exactly. Sometimes a rich Domain Model has no real value, for instance in the reporting case you mention. Other cases I've seen are Web services which are babysitting a database. Or Web apps which invoke business logic on the mainframe. Creating or replicating the logic in Java makes little sense with me in those cases. For the record, I like rich Domain Models, and use them quite a lot. I also advice customers to use them. However, and that's the point of the article, they are not applicable everywhere.
  24. Re: whatever.[ Go to top ]

    For the record, I like rich Domain Models, and use them quite a lot. I also advice customers to use them. However, and that's the point of the article, they are not applicable everywhere.
    Definitely true. No silver bullet. However, you stated in your article that the need to persist data in a relational DB forces developers to create anemic domain models. This is wrong: the centrality of the database does not mandate that objects that are mapped to tables lack logic, barring the option that everything is done via stored procedures. But, assuming the business logic of an app is implemented in Java, and that you have an object that maps your table, there is no need to delegate business logic to external, "service" classes that use the getter/setter methods of your domain objects to retrieve and store data. Just add business methods to your domain objects: this will do them no harm. Of course, you may still want to leave some algorhythms implemented outside the object because they use a different business logic, but this does not mean that you must implement all procedures outside the object.
  25. Re: whatever.[ Go to top ]

    However, you stated in your article that the need to persist data in a relational DB forces developers to create anemic domain models. This is wrong: the centrality of the database does not mandate that objects that are mapped to tables lack logic, barring the option that everything is done via stored procedures.
    Actually, I didn't say that, Joseph wrote that in the summary. And I agree with you: if you do need to create new business logic, and you are using a domain model, the best place to put is in the domain model.
  26. Indeed. I wrote that, because I've seen nothing to make a relational database store a rich domain - it stores tuple state and little more, except in a few rare cases.
  27. Indeed. I wrote that, because I've seen nothing to make a relational database store a rich domain - it stores tuple state and little more, except in a few rare cases.
    Ach! Our Honorable Moderator caused a misunderstanding. I miss good ol' Floyd. Well, at least you gave me an excuse to write something semi-sensible in the document i am producing today. Ok, to the serious stuff now. I agree that no ORM can store the "richness" of a rich domain, since that is code and not data and I have yet to find a tool that maps bytecode to database. Java to PL/SQL conversion tool anyone? I can name several people that would appreciate it a lot, but I am not one. But, ahem, even if the "rich" part is not stored, what on earth does prevent the designer to map a non-anemic domain model to a database? Apart from the Bad Habit of doing it, I mean. @Udayan Patel: Fowler is no pope, as nobody pretends to be one here. But until I read his article on "Anemic Domain Models" I had not realized that I myself had acquired a "bad habit". I just have a question for you: what prevents a domain object from being serializable, and so usable as an argument for remote calls? When all we had for persistence was EJB 1.x the DTO proliferation was mandatory, for having EJB refs wandering in the system was pure folly. But ORM has stopped all this, since it lets you write an object that can achieve all goals: serializability, persistence, business logic implementation.
  28. @Udayan Patel: Fowler is no pope, as nobody pretends to be one here. But until I read his article on "Anemic Domain Models" I had not realized that I myself had acquired a "bad habit".I just have a question for you: what prevents a domain object from being serializable, and so usable as an argument for remote calls?
    Fowler is no pope? How do you explain you changing your programming style after reading his article which told you it is a bad practice? Back it up why is it a bad practice? Hummmmmm so you don't mind being your domain object serialized! I defenately mind. I really am not interested in loosing built in JVM protection for my domain model. I honestly am reluctunt to provide my class's behavior to a remote party or to my http session in serialized form.
    When all we had for persistence was EJB 1.x the DTO proliferation was mandatory, for having EJB refs wandering in the system was pure folly.
    No. EJB is a remote call and serialized DTOs were needed to complete remote call. It wasn't proliferation it was a need.
    But ORM has stopped all this, since it lets you write an object that can achieve all goals: serializability, persistence, business logic implementation.
    No. Getting rid of EJB from application got rid of it. hummmm, why do you really want to serialize your business stuff. Don't you want to draw a clear lines between your layers? and keep tight control over how much information the otherside should be getting?

  29. Fowler is no pope? How do you explain you changing your programming style after reading his article which told you it is a bad practice? Back it up why is it a bad practice?
    I simply realized I had given up a good OO design practice (the object is responsible for enforcing its internal consistence) to pursue absolute separation of tiers via excessive usage of the JavaBean pattern, as some so-called enterprise gurus suggested. But self-consistence of objects is more important than layer separation.
    Hummmmmm so you don't mind being your domain object serialized! I defenately mind. I really am not interested in loosing built in JVM protection for my domain model. I honestly am reluctunt to provide my class's behavior to a remote party or to my http session in serialized form.
    Why? Once the object is transferred to the web layer there is nothing harmful the dumb web programmer (sorry, you JSP crunchers, I do not believe you are dumb, but I do not know whether he does) can do to your object, as it has lost its persistence capabilities. It is when the object is logicless that the JavaScript guy has no tools to check whether what he is doing with the object is right, and risks sending back a non-consistent instance to the business layer. Hence the duplication of basic business logic (data integrity, etc) in the tiers. Which is not a good practice, whether you believe it or not.

    No. EJB is a remote call and serialized DTOs were needed to complete remote call. It wasn't proliferation it was a need.
    I meant "Proliferation of stupid DTOs". You definitely need them with EJB 1-2, sure.

    But ORM has stopped all this, since it lets you write an object that can achieve all goals: serializability, persistence, business logic implementation.

    No. Getting rid of EJB from application got rid of it. hummmm, why do you really want to serialize your business stuff. Don't you want to draw a clear lines between your layers? and keep tight control over how much information the otherside should be getting?
    Let's say that getting rid of EJB 2.x did the trick, instead. I DO have a clear line between layers with a serializable non-anemic object. If you use an EJB/WS call (EJB preferred) betweeen web and business tier, your objects are serialized (or checked for serializability) and transactions are managed by the application container before the web page is allowed to mangle your objects. You do not risk leaving the HTML-rendering code in control of open DB connections attached to objects or other very dangerous events that can take place in poorly-designed two-tiered applications. And if you do not want to give an information to the web tier, just delete it from the object before returning it. It can still function as a dumb object. It is just that it does not have to be dumb. What I really hate is having systems that must behave in a certain way, and do not leave me the choice.
  30. But self-consistence of objects is more important than layer separation.
    Since when and Why? Rain check on other stuff for a little.
  31. Re: whatever.[ Go to top ]

    I think the point that Arjen was trying to make is that sometimes you have to start from a relational model. You can't always design the domain model first and *then* think of persistence. Mind you, this is not an edge case. Virtually all reporting applications of scale need to start with schema design. There is simply no business logic that would make sense to put in Java (or Ruby or whatever)--all possible operations are expressed in the schema and SQL queries. Hence an anemic domain.


    Exactly. Sometimes a rich Domain Model has no real value, for instance in the reporting case you mention. Other cases I've seen are Web services which are babysitting a database. Or Web apps which invoke business logic on the mainframe. Creating or replicating the logic in Java makes little sense with me in those cases.

    For the record, I like rich Domain Models, and use them quite a lot. I also advice customers to use them. However, and that's the point of the article, they are not applicable everywhere.
    Arjen, This isn't the focus of the thread, but it seemed to me that your blog is more about th impedence mismatch among the object graph, relational database, and HTML rendering - and how absurd it is that we have to deal with it. If that's the case, I agree completely that repeatedly dealing with the impedance mismatch is absolutely absurd, and that it is extremely difficult (impossible?) to deal with without either making the model in at least one layer anemic or duplicating logic across layers. ...that being said... I'd like to propose a new Anti-pattern (forgive me if it alrady exists, I did not bother googling it): The anemic relational model. It is where the database is used as a "dumb transactional datastore" that does little or nothing to ensure the integrity of its data. It includes any practice that makes it extremely difficult to update the database without either going through the application or risking corrupting the data.
  32. Re: whatever.[ Go to top ]

    I'd like to propose a new Anti-pattern (forgive me if it alrady exists, I did not bother googling it):

    The anemic relational model.

    It is where the database is used as a "dumb transactional datastore" that does little or nothing to ensure the integrity of its data. It includes any practice that makes it extremely difficult to update the database without either going through the application or risking corrupting the data.
    I think that domain models can express integrity constraints that go far beyond the capabilities of RDBMS. You may say that it is possible to use DB triggers to ensure such constraints but here we must agree if this triggers must be considered as part of an application or not. More, triggers would deal with rows, not objects, if this matters somehow. Guido
  33. Re: whatever.[ Go to top ]

    I'd like to propose a new Anti-pattern (forgive me if it alrady exists, I did not bother googling it):

    The anemic relational model.

    It is where the database is used as a "dumb transactional datastore" that does little or nothing to ensure the integrity of its data. It includes any practice that makes it extremely difficult to update the database without either going through the application or risking corrupting the data.

    I think that domain models can express integrity constraints that go far beyond the capabilities of RDBMS.
    You may say that it is possible to use DB triggers to ensure such constraints but here we must agree if this triggers must be considered as part of an application or not.
    More, triggers would deal with rows, not objects, if this matters somehow.

    Guido
    You shouldn't be so dogmatic about OO approach being better than relational (sorry, still influenced by the comment about "pope" Fowler :) ). I do remember having to cope with examples of "anemic relational models", and it was not better than dealing with an anemic object model. A trigger is by definition not part of an application but of the database. And a cleverly designed trigger or stored procedure can do everything you can do in Java apps, as it is not limited to interacting with just one table. Of course SQL code that implements complex logic is somehow less readable than the equivalent Java or C code, and debugging within a RDBMS is less user-friendly than debugging in eclipse or whatever tool you use in Java. And yes, a trigger works on a record, not an object. And a tuple is not an object. But does it mean that it stinks because it conforms to the relational model and not the OO model?
  34. Re: whatever.[ Go to top ]

    I'd like to propose a new Anti-pattern (forgive me if it alrady exists, I did not bother googling it):

    The anemic relational model.

    It is where the database is used as a "dumb transactional datastore" that does little or nothing to ensure the integrity of its data. It includes any practice that makes it extremely difficult to update the database without either going through the application or risking corrupting the data.

    I think that domain models can express integrity constraints that go far beyond the capabilities of RDBMS.
    You may say that it is possible to use DB triggers to ensure such constraints but here we must agree if this triggers must be considered as part of an application or not.
    More, triggers would deal with rows, not objects, if this matters somehow.

    Guido


    You shouldn't be so dogmatic about OO approach being better than relational (sorry, still influenced by the comment about "pope" Fowler :) ). I do remember having to cope with examples of "anemic relational models", and it was not better than dealing with an anemic object model.

    A trigger is by definition not part of an application but of the database. And a cleverly designed trigger or stored procedure can do everything you can do in Java apps, as it is not limited to interacting with just one table. Of course SQL code that implements complex logic is somehow less readable than the equivalent Java or C code, and debugging within a RDBMS is less user-friendly than debugging in eclipse or whatever tool you use in Java.

    And yes, a trigger works on a record, not an object. And a tuple is not an object. But does it mean that it stinks because it conforms to the relational model and not the OO model?
    It is not a matter of being dogmatic or OO dogmatic. It is a matter of life and I have purposely used the term domain model indicating a representation of reality. I mean that certain (complex) constraints are part of the reality of the domain and not an artificial over-analisys outcome. About trigger. Do you assume that a trigger is part of the database because it is activated whatever application acts on the DB ? Yes, it might be reasonable, but pushing to the edge this approach leads to the implementation of the domain entities (objects ?) with DBMS language and constructs. And no, a tuple does not stink because is a tuple. Simply you have the impedence mismatch back. Well, nothing you can't cope with, simply la little harder. Guido
  35. Re: whatever.[ Go to top ]

    I think that domain models can express integrity constraints that go far beyond the capabilities of RDBMS.
    That's very true. For example, how do you declaritively (i.e. not with a trigger and stored procedure) define that a set of related tuples must for a acyclic directed graph? (If you know how to do this easily, please tell me.) It's pretty easy to do, at least in a naive O(n) fashion, in OO code. Which is probably why it's hard to do it in today's RBMSes. No one wants an O(n) check every time they insert a row or update a certain field on a row. So I understand enforcing that in the OO part of the domain model and not in the relational model. At the end of the day, you have to do what makes sense. You know N is never going to be bigger, than, say 20. But that's no excuse to fail to define foreign key, primary key, not null, or other constraints that are very easily expressed in the relational model. --------- I think the impedance mismatch is a more interesting topic. Let's say you have a string field that needs to be validated using a regular expression. This is pretty easy to do in your mutator method, and it's easy to define as a constraint in the database. So do you put it both places? Of course the DB and Java end up using slightly different regex syntax, so do you write the regex twice? Do you write a regex abstraction layer that translates Hibernate Regular Expressions (I don't think there is a such a thing) into Oracle or PostgreSQL regular expressions and Java regular expressions? What about JavaScript for client-side validation? What about in some Java form object that exist prior to the domain object being created? That's 4 different places. So you refactor it into a 5th place, call it a "validator" and make every other place call it...or at least call it before moving the data from one place to the next. Ughh...all that complexity. What in one layer is just a simple check becomes a tangled mess because of the impedance mismatch among the different layers.
  36. Re: whatever.[ Go to top ]

    However, you stated in your article that the need to persist data in a relational DB forces developers to create anemic domain models. This is wrong: the centrality of the database does not mandate that objects that are mapped to tables lack logic, barring the option that everything is done via stored procedures.
    I agree. The choice between combining domain model and some subset of logic is there for you. Domain Driven Design and Pojo's in Action are two books that advocate combining these. I see this as intriguing, but I'm conservative on this point, having done many projects with "anemic" domain models that were successful. As I'll argue below, I don't think it's actually easy to translate the "rich domain model" dogma into a yes/no testable criteria, let alone one that I can, today, defend well with a reasoned argument. Unless or until that occurs, I will stick with my present belief that action logic is a separate concern that should be encapsulated and separated in a different layer. With the two notable books above saying I should change, I'm willing to listen to such an argument, but this alone is not persuasive, since it's based solely on appeal to authority. I see a lot of value in structuring my domain code in such a way that it can be reused. I reuse my domain objects a lot -- in separate tiers, as transport mechanisms across systems, in GUI's etc... I don't want a whole bunch of action logic that only makes sense in one context to be in the class unless everybody that uses the domain object could reasonable use it. To me, "separatation of concerns" is a principal that I deeply believe in and it seems to apply here and I don't want to give it up without a really good argument, which I haven't heard yet. For example, let's say I have a Server class and a NetworkInterface class and an IP class, with one-to-many relations between each in three levels. One thing that an IP, a NetweorkInterface, and a Server might want to do is verify that it is operational via ping. Fine, but I would not provide the implementation of a "ping" method in any of these classes, as the "rich domain" advocates would tell me to do. The reason I don't is that this doesn't make sense everywhere I might care about these objects. In my asset tracking system I don't care if the systems are operational. Yet I might have it in other systems. There's no guarantee that on the system where I care about these domain objects that I even have network connectivity sufficient to check this. So, if I follow the "rich domain model" across an enterprise, I end up with an extremely fat domain class that has methods that may or may not make sense whereever I happen to be using the domain object. No thanks. Instead, I'd write a PingAction or some kind of monitoring service, and put the ping functionality there and any systems that cared could call it from there. In particular, in an SOA, I only want one system to perform this action and other systems that want it done would interface to it, maybe directly or via a bus, so I really wouldn't want the ping implementation code to live in the IP ojbect itself. The argument for rich domain model seems to ignore the fact that almost all behavior within the domain is contextual. To me, this is a really good reason to use delegation, so I often write action classes and business logic that has get/set methods for the domain class upon which it depends. Some people claim that my domain object itself is not a True Object in some sense they can't or won't define that appearantly depends on religeous inspiration. I disagree and haven't had the requisite religious enlightenment. I don't understand the supposed rule that "real" behavior is more than getters and setters. How do you know what I'm doing when I get or set a variable? There's no real distinction here! I can put any behavior you want in an get/set invocation pattern. As dependency injection gains populatrity this becomes even more convenience/prefered. BUT, even if all my get/set methods are trivial, that doesn't mean that I won't override them, or more likely, intercept them with AOP style functionality using Spring or whatnot. So maybe just to annoy the rich content snobs I would subclass my server object with a PingableServer child class that has a pingAttempt field and an interceptor on the set for it that proxies to my PingAction and pokes the result back into the pingAttempt object. Is this "rich domain model"? Heh. Often I add get/set methods that are non-trivial. Consider collection convenience methods, to simplify aggregation/iteration. For example, if I want all of the IP's for a server I call myServer.getIPs(), instead of having to externally call getNetworkInterfaces(), and merge the results of getIPs() on each of these. Is this "behavior" rich enough to qualify for "rich domain model"? If it's a foolish discrimination against get/set, then how about if I have my Server class implements a method addNetworkInterface that establishes a bidirection relationship in a consistent manner that is more convenient than having a setter for a collection. Is that enough? It's still only managing the relationship between the domain elements. This is less rich than the previous two examples. The bottom line is that I can't even tell how to look at a domain model and decide if it is "anemic", though if I concluded that it was, I don't know why I really think that's a bad thing. I could always subclass it locally to add the rich behavior appropriate for the local system.
  37. Re: whatever.[ Go to top ]

    Exactly. Sometimes a rich Domain Model has no real value, for instance in the reporting case you mention. Other cases I've seen are Web services which are babysitting a database. Or Web apps which invoke business logic on the mainframe. Creating or replicating the logic in Java makes little sense with me in those cases.

    For the record, I like rich Domain Models, and use them quite a lot. I also advice customers to use them. However, and that's the point of the article, they are not applicable everywhere.
    In addition to this I would like to state that the Domain Model often helps to communicate with the business or end user to define how the business process actually works. The translation into a technical architecture is then up to us. You don't want to hassle the business or end user with an RDBMS schema or design. Furthermore I think a Domain Model should be implementation independent. So the implementation of the application can reside anywhere although any OO language is very suitable for implementing a Domain Model. I agree that a rich Domain Model can become an overkill for applications that have already been built and are non OO languages. Regards, Yuri
  38. Re: whatever.[ Go to top ]

    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 and other tools are some efforts in this direction ;-) My 0,02 Luca Garulli AssetData.it
  39. Re: whatever.[ Go to top ]

    Java monkeys who think OO is a silver bullet should be getting out of the business or resigning themselves to becoming maintenance blubs.
    Calling people Monkeys? Frank, are you having a bad day or is this an issue of low self-esteem?
  40. Re: whatever.[ Go to top ]

    Java monkeys who think OO is a silver bullet should be getting out of the business or resigning themselves to becoming maintenance blubs.


    Calling people Monkeys? Frank, are you having a bad day or is this an issue of low self-esteem?
    "Race Condition", what's the matter with you being called a Java monkey? You're loving it. You know everything about OO (well everything in between the curly braces of class Blub). Hell, you'd probably be on track to gross $400K this year if you were doing COBOL. They really pull in the cash. Still not as much as David Hansen Hasselhoff though ;)
  41. Re: whatever. (Chill a little, eh?)[ Go to top ]

    Guys, be kind to one another. It's a good way to be. Really. To me, the point about anemic models in the database is because in an RDMS you *typically* don't find much functionality - just static data. That means that a persistence layer like JPA, or Hibernate, or JDO just translates the anemic model into something less anemic - and that's a translation, period. Translating further is translating further, it's not an initial step.
  42. Re: whatever.[ Go to top ]

    Java monkeys who think OO is a silver bullet should be getting out of the business or resigning themselves to becoming maintenance blubs.


    Calling people Monkeys? Frank, are you having a bad day or is this an issue of low self-esteem?


    "Race Condition", what's the matter with you being called a Java monkey? You're loving it. You know everything about OO (well everything in between the curly braces of class Blub). Hell, you'd probably be on track to gross $400K this year if you were doing COBOL. They really pull in the cash.
    Still not as much as David Hansen Hasselhoff though ;)
    Zing! Sorry to such a prick. Peace.
  43. Re: whatever.[ Go to top ]

    Zing! Sorry to such a prick. Peace.
    +1 insightful
  44. Troll alert.[ Go to top ]

    Ignore. Do not respond at any cost.
  45. Re: whatever.[ Go to top ]

    "which forces an anemic model"??? What a load of crap.
    I completely agree with this. IMO the domain model with it's fine-grained objects is the only chance we have to master the overwhelming complexity which our industry sometimes has to cope with. Bloated stateless service layers simply lead to a maintenance nightmare in the long run. It's so sad to see that so many people in our industry just don't seem to 'get' it.
    I have spent more than half of my career fixing other people's code that use this same idea.
    Glad to hear that I'm not the only one! :-)
    If you don't understand how to use OO, please get out of the business.
    +1
  46. Re: whatever.[ Go to top ]

    "which forces an anemic model"??? What a load of crap.


    I completely agree with this. IMO the domain model with it's fine-grained objects is the only chance we have to master the overwhelming complexity which our industry sometimes has to cope with. Bloated stateless service layers simply lead to a maintenance nightmare in the long run. It's so sad to see that so many people in our industry just don't seem to 'get' it.


    I have spent more than half of my career fixing other people's code that use this same idea.


    Glad to hear that I'm not the only one! :-)


    If you don't understand how to use OO, please get out of the business.


    +1
    No, your are not the only ones. I have seen the centrality of the database lead to a complex flights plan management application in just one class. Guido.
  47. Yall has gots gas[ Go to top ]

    You wascals!
  48. Re: Arjen Poutsma: Domain Drivel[ Go to top ]

    Ha hah a ha ha I love this, Starting from unit test one by one OO concepts are being critisized. Could open standerd are to blame? Or is it that too many people tried to enforced their personal agenda onto developers? Whatever it is, I couldn't be more careless.
  49. Next on TSS...[ Go to top ]

    Next on TSS... "GOTO's Really Aren't as Bad as Believed"
  50. Re: Next on TSS...[ Go to top ]

    We don't call them GOTO's any more we call them closures. Some people, really...
  51. Re: Arjen Poutsma: Domain Drivel[ Go to top ]

    "Anemic domain model", lets just say my a$$.
    Even if Martin Flowler insist on it I still would say samething. Inception of J2EE aapplication guidelines started out with DTO/VO and has been that way. All these big guns talking now interms of "Anemic domain model" where were they when it was time to distinguish between domain model V/S serializable objects for front end/RMI calls to backup their terminology. When the term Anemic domain model was coined, for people it was religious commendment to follow without thinking for a second because honorable pope Martin Folwer says so. Bring it ouwn...
  52. Re: Arjen Poutsma: Domain Drivel[ Go to top ]

    This thread is pretty funny in light of the one about John Davies POD.