On the anemic domain…
I have found this topic very interesting to study over the past few months, and I’ve found a lot of people doing the anemic domain successfully. But for me, it all comes back to what is tried and true, and what I value.

Object oriented principles offer all kinds of benefits that naturally lead you into “the pit of success” (I hate that phrase, but it seemed fitting). More importantly, writing good classes alleviates the most important problem with software: complexity.

As McConnell says “design is a wicked problem” … a delicate balance of forces that are in opposition. My only goal in providing feedback is to spark dialog and creativity to these hard design questions - so we can get better at what we do.

To be honest though, this discussion would be better sitting at a round table with a beer in hand :) Let me know when and where.

I would ask, why should your domain entities care about presentation concerns? And why should your presentation objects care about domain logic? These are orthognal concerns. So in an effort to keep the system MORE maintainable these orthogonal concerns should be kept… well, separate. (see: Separation of Concerns)

>> On my current project, things go much faster. I can drag my database tables onto the LINQ to SQL designer and immediately I have my entity objects created and I can load and save them to the database. I can immediately go and start writing code that has business value.

Drag-n-dropping of tables to generate entities is very typical in data-centric approaches. But, does “time savings” gained by mapping your entities directly from the persistence mechanism really mean you’re delivering more business value? Does your database really model the way the business works, or more importantly, the way the business wants to work? How much value is lost in missed opportunities because you’ve now artificially tied yourself to a sub-optimal, relationally constrained, model… a model that does not translate well to object oriented code?

We need to forget about the database for a bit and instead work with the domain experts to come up with a shared understanding of how to model the domain. That model will of course be wrong, but by working with the domain experts to continually refine our the model we can eventually get closer and closer to a true representation of how the business works… meaning we can more accurately deliver the value the business really needs.

Of course, what I’m talking about is nothing new. I’m just rehashing many of the ideas promoted by DDD, as you’ve mentioned.

You’ve said that DDD makes sense when dealing with complex domain models. And knowing what I do about your particular project, I’d say it is a complex domain. And the point of DDD is not just to create a “super-elegant business layer” - it is to build a well understood model of a complex business domain, allowing you to deliver more value. The point is to allow you to focus on the core competencies of the business… the things that make the business unique, b/c thats is where real value will be found.

As to the question of the Anemic Domain Anti-Pattern - sometimes just passing around bit-buckets makes sense… but when dealing with complex domains, why not do what OO was designed to and try to model the domain and encapsulate the complexity? We need to get back to our OO fundamentals.

Secondly, all this discussion is absolutely healthy. We need a pragmatic mindset when choosing our approaches to these sorts of problems — and it’s absolutely not black and white or a simple decision in most all our projects.

Speed to market, maintainability, flexibility, clarity. Nice things to think about, often hard to bundle all together at once.

FWIW, I think the success of your project is testiment enough to the validity of the approaches you took.

On the other hand, I see things that ARE accomplishable, or that just rub me the wrong way personally. In the past three projects, I’ve never liked the fact that all our business knowledge seems to reside outside the entities, which to me are the only logical place for that knowledge to be. In my mind, the Client class should the end-all authority on all “Client-y” things.

Persistence ignorance? Who cares? It’s a goal, sure, but not one to sacrifice the rest of your project for. On my first project for Quick I saw it pay off, big time, when they switched from Oracle to SQL Server over the weekend, and I didn’t even notice on Monday morning. That’s awesome… it’s also the only time I’ve ever seen it happen in 15+ years of doing this stuff. Very cool, but it’s like Haley’s comet… you MIGHT live to see it pay off once in your life… maybe.

I’m fine with Linq to Sql entities not being persistence-ignorant, so long as I’m doing my work in the other half of the partial class. It’s not “pure”, but I can pretend that the other half of the class isn’t there, and go about my business. It’s not perfect, but it’ll do for now. I’d much rather have some sophisticated mapping like NHibernate, but not until it is as easy to maintain as Linq to Sql is now. Maybe the Entity Framework will get us there, maybe not, we’ll just see when it’s released I guess.

So yes, I see all the points, and they’re all valid. In a world with an unlimited budget and timeline I would absolutely opt for the architecturally correct way of doing things. We don’t live in that perfect world of endless green fields, though. Our fields are brown, and customers want results NOW.

>> I would ask, why should your domain entities care about presentation concerns? And why should your presentation objects care about domain logic? These are orthognal concerns. So in an effort to keep the system MORE maintainable these orthogonal concerns should be kept… well, separate. (see: Separation of Concerns)

I agree, but is it worth the time to create separate entities, DTOs, and translators to fix this problem? You could say this about a web app too (that’s not using web services), but you wouldn’t make separate entity objects in that case.

About DDD… I think this is a good example of what Alexei was saying when he said that everything depends on the business situation. Because if we were doing our current project from the ground up, you’re exactly right, we have a very complex domain model and DDD would be the correct way to go. In our case, we were stuck with a database structure and had to live with it, so I think the way that we did it made sense (LINQ to SQL somewhat constrained us vs. what we could do with NHibernate).

On the anemic domain…
I have found this topic very interesting to study over the past few months, and I’ve found a lot of people doing the anemic domain successfully. But for me, it all comes back to what is tried and true, and what I value.

Object oriented principles offer all kinds of benefits that naturally lead you into “the pit of success” (I hate that phrase, but it seemed fitting). More importantly, writing good classes alleviates the most important problem with software: complexity.

As McConnell says “design is a wicked problem” … a delicate balance of forces that are in opposition. My only goal in providing feedback is to spark dialog and creativity to these hard design questions - so we can get better at what we do.

To be honest though, this discussion would be better sitting at a round table with a beer in hand :) Let me know when and where.

The point is to keep improving. And we do that by uncovering a pain point and then addressing and alleviating it. Then we lower our pain threshold just a little more, find the next pain point, and work to alleviate it, continuing ad nauseam.

Rather than taking those bits of feedback as an attack, look at them for what they are - real people giving real feedback about what caused them pain. Then address those pains and move forward. The goal is perfection - but we can only hope to get there through continuous improvement. :)

No offense taken. I’m always up for a good debate and I’m always open to changing things. I just wanted to say my side of the story.