small update
Saturday, August 20th, 2005I have updated my IndependentDomainModel pattern with a short toy code sample that shows the main idea of the pattern; that domain logic should be able to execute without access to services.
I have updated my IndependentDomainModel pattern with a short toy code sample that shows the main idea of the pattern; that domain logic should be able to execute without access to services.
I’ve posted the first of several new design patterns I am working on. IndependentDomainModel describes an approach to object-oriented domain models for distributed systems. SymmetricLayers Describes a complimentary layering scheme, also for distributed enterprise apps. Its not perfect or complete yet, but good enough to add something useful I think.
He has a lot of interesting things to say, mostly about the problems with using a class based domain model. I wish he wouldn’t make so many sweeping generalizations against oop in general though. Procedural and relational models are only a subset of what can be achieved using OOP. I guess he […]
Tonight it suddenly dawned on me a way to document all the stuff I’ve been trying to get out in my blog in a neat set of conventional design patterns. Sweet.
Sharp kid. Wish I had have figured all that out before I finished college
It seems that a lot of stuff ends up in “domain” or “business” objects that is not actually domain logic. I’ve done this myself, but i always find it something painful about it. There’s always this nagging feeling that something is wrong.
Here is my list of things that don’t belong in your domain […]
I’ve come up with this list of ways that programmers tend to deal with problems of code duplication.
1) Run with it - hire 1-50 more people so to write and maintain more of the same code. This seems to be a common practice in large corporations. The problem with this solution is that […]
The problem here is that most business applications don’t actually have a lot of “business logic” in them. Other than basic validation of user input, mainly what we do with objects is Create, Read, Update, and Delete them. There simply isn’t always a need to have a lot of fancy domain logic associated with your […]
I’ve been reading a lot of blogs lately by object-oriented people who complain about the increasing separation of code and data in the domain layer. They claim that in good object-oriented programming the behavior and the data are supposed to go together. While this is true in principle, it doesn’t necessarily mean that […]
I’ve had a minor obsession going with aop lately. Maybe it’s that I think there’s something valuable there but can’t quite pinpoint it, or maybe that its that it’s getting way more attention than it deserves. But as I read articles, blogs, introductions, papers, etc… I’ve noticed one consistent thing that always […]