Amen.

Nice article - welcome back.

If you eschew the Repository concept, or any domain-specific data access interface, do you end up with a collection of transaction scripts that contain logic that might otherwise rest cohesively in domain objects?  Is this the slippery slope to what Fowler called out as the "Anemic Domain Model" design smell?

To add to what Scott said

1. Do you always start new projects as if it is the first time you code - don't you have anything you take from your previous ones? You don't want to future-proof just for kicks but if you know (looking at past projects) that you can reuse something, or know that this is something that is more volatile etc

.

2. Software spends much more time in maintenance that in development (if it is any good) - again you don't have to make your solution ever so flexible (to the point it would take ages to complete and be overly complex) but if you look at your past projects there are probably some conclusions you can draw as to what get changed more often

Arnon

Having worked with CSLA, I have to say I abandoned Rocky's approach, even though I favored it at one time.  Having all the data access code in or even called by business objects really bloats them.  It is possible to get the "High Cohesion" and the Encapsulation at the same time, depending on what framework or O/R Mapper you are using.  For example, in the Wilson O/R Mapper, your objects' data can be neatly encapsulated behind public properties and methods, and only by reflection or thru implementation of a specific interface does the object reveal its internal data to the O/R Mapper engine (which in this case is effectively the DAL) for persistence purposes.  So your data is generally not exposed by data access methods or public fields/properties but resting safely behind the business layer.  Finally, the business object can respond to events that tell it when it is about to be inserted, updated, deleted, etc. so that it can perform business logic related to persistence, but it doesn't necessarily have to know about how its being persisted, such as the drivers, sql statements, or database used.

So in my opinion, this meets both principles: The business object is well encapsulated, by limiting exposure of its internals ONLY to the DAL/ORM Layer.  The business object also has high cohesion, in that it only handles its own business logic, and not all the mechanics of data access and persistence.  

Of course, there is no reason you have to use an O/R Mapper to meet these needs, you could write your own BLL and DAL using this kind of structure.  

Other than that, I agree with you.  There is no point in every one of my domain classes to implement a matching interface detailing all their properties, and have each domain class that references another do so only thru that interface rather than by concrete types.  That level of flexibility/loose coupling just isn't necessary in most cases.  But its good to have the tools and the know how for when it IS necessary or useful.  

Most OO pattern books tend to tell you the trade-offs in using a pattern as well.  You have to make a judgement call when you apply a pattern, and not just use it repeatedly for its own sake.  Thats kind of the "pre-mature" optimzation/abstraction evil.

Dave,

So this is what I'm trying to figure out.  In my exploration of TDD (I'm talking mostly test-driven, but not necessarily test-first), the CodeBetter blogs have been invaluable.  So when I came across this post of yours, the confusion started to set in.  Here's why.  I did not see the word "test" or "mock" anywhere in your post.

From everything that I have uncovered about loose coupling and high cohesion, it has been all about testability.  IMHO, one of the major short-comings that I had prior to the past 2 years of research into TDD is a complete lack of understanding about how to use interfaces, and even why they really needed to exist.  "The day the light shown" was the day I finally came across mock objects.  I still have not used them in practice, but I feel that I actually "get it" about them, and loose coupling, and high cohesion, and dependency injection, etc.

I fully agree with your statements on over-architecting or over-engineering your solution for the sake of being "pluggable" without the requirements to do so.  BUT IMHO, if you are doing so for the sake of testability, then loose coupling principles becomes invaluable.

Thoughts???

David,

How much of your problems with pluggability leading to unnecessary complexity are related to speculative designing upfront?  If you're trying to guess or plan for extensibility upfront it's easy to go astray or overcomplicate things.  What I've found is to just let the need for testability lead to the abstraction points.  We put abstracted interfaces in every place where it's convenient to substitute a mock object in tests.  I think we actually get better extensibility now as a side effect of TDD than I did on previous projects where I obsessed over putting in the "right" extensibility points.

I think that extensibility is going to follow from being religiously fastidious about assigning responsibilities with the Single Responsibility Principle.

David,

I hear what you're saying.  I know it's dogmatic, but I'd say that "Future-proofing" is best accomplished through squeaky clean code with a high degree of testability and automated test coverage.  The odds of making any change easily are better that way than backing yourself into a corner by enabling only a certain kind of future change through pluggability.  Besides, with clean, tested code you can always back in an extensibility point later.

Good post, good discussion.

David,

BigJimInDC brings up a great point. I will pick on your respository example.

For the repository example it is also important to note that there is a trade off to something like active record (especially in testability and reusability). One of the great bits about the repository pattern is that you can easily mock out a repository for when you are unit testing. A repository shows an outward contract of holding all items in memory (just make it actually hold all items in memory). Since it has been externalized you can quite easily make a repository that deals with other types of sources (as an example I have had repositories that deal witha  prevalence layer) I can change them out that deal with repositories that use an OR mapper and most importantly I can use both versions without requiring a branch of the source.

Aside from that the existence of a repository shows a design decision on that object. Namely that the object is considerred an aggregate root. With something more like what Rocky subscribes to every object is generally considerred an aggregate root (they also generally match 1-1 with database objects). I will stay away from the impedance discussion but I would guess that you are most likely sufferring from some problems as the other methodologies push you down a 1 model "solution" and frankly the database model is generally a poor model for a domain.

"that suggests using a separate persistent object in another layer."

Or using the repository pattern and externalizing the accessor methods to another class so things such as polymorphism can be used on them.

I also think its great that someone brings up the single responsibility principle since active record (or Rocky's suggestion) as a whole is a violation of it. If you are following single resposibility you will end up with the repository pattern.

I am far from saying that I use them only for testability ... I am saying that it is a great by product and the alternative is a constant pain as the static method based systems do not support polymorphism.

DDD p 152

Repositories have many advantages including the following.

-They present clients with a simple model for obtaining persistent objects and managing their life cycle

-They decouple applications and domain design from persistence technology, multiple database strategies, or even multiple data sources

-They communicate design decisions about object access [aggregate roots]

-They allow easy substitution of a dummy implementation, for use in testing (typically using an in-memory collection)

I use them for many things, as I stated I use them for testing (in memory collections). I also have in applications different versions of repositories (example a domain that runs with a prevalence layer and with an OR mapper depending on client configuration of the repositories).

The static method methodology is doomed to fail in this case as you have lost polymorphism it is not feasable to have a domain run concurrently in multiple contexts unless whatever mechanism you are using in your static methods supports both contexts. The moment you start trying to reuse a domain you tend to end up with multiple contexts (like in the example of needing to work with both a prevalence layer and an OR mapper). Unit testing will often implicitly bring multiple contexts as you do not wish to hit the database (an OR mapper hitting an xml file is kind of a solution but I prefer the repeatability of having actual repositories who have their data loaded through code as depending on the xml file brings in another dependency for tests to work.

Another nice side benefit dealing with testing is that I have a very clear line when it comes to integration vs unit testing. All of the domain is unit tested with in memory versions of the repositories (fast, easy setup/tear down, etc). My integration tests for my domain (data access) are simply making sure that my repositories work correctly (i.e. the tests I wrote for my abstract repository contract but run against a real data source). Providing my domain works with the in memory versions correctly and the repositories have been tested against their actual data source I can reasonably expect that the domain will now work with the data source after running my integration tests (providing the tests reasonably express the behavior of the repository)

While my repositories are fairly thin objects to say an OR mapper they also give me the ability to change the data source etc that my domain is running against without having to change the domain itself.

I think it should be noted here that the only real difference is the pulling out of the data access parts to another object to allow for polymorphism which in my mind is a good thing. I guess my reason for using repository is that it is very little extra code to begin with (putting the data access methods in their own class (following the single reponsibility principle) and creating an interface). By spending this very small amount of work up front I rid myself of the huge pain of having to try to support multiple concurrent contexts without it (which would in many cases require a source branch or lots of nasty if statements). While in many cases I may only use a single repository as my OR mapper handles things for me, it sure is nice to have the insurance policy of being able to change it if I have to, the benefit of this will only be recognized when you have to do it (remember that you have type coupling on all of those static methods in every client that accesses your domain).

Dave,

I couldn't have written your reply to me any better than you did.  Point being, we're in complete agreement on everything you raised in the reply.  I initially simply read your post as a statement about loose coupling in general, and did not necessarily pick up on "speculative design" being the core angle you were attacking the issue from.

I believe that Greg's points about the repository situation have more to do with a series of unstated logical leaps on his part (and many others), rather than any given promotion of premature or speculative design.  IMHO, the use of patterns, repositories, etc is as speculative as deciding to use OO approaches over a strictly procedural approach.  If you have already decided to use OO, then following what is laid out in Evans' and Nilsson's books is a very smart idea.

In general, my point of bringing testability into the picture is that I firmly believe testability is a very good thing to aim for, much as Jeremy so eloquently stated.  If you do not agree with that, or not as much as we do, then our opinions downstream will surely differ.  But playing with the idea that you do agree with us, then potentially performing what you want to label as speculative design to support/enhance testability also becomes a very good thing.

"Just to make sure we are clear, I am not arguing CSLA, ActiveRecord, vs. DDD in this post. My example of CSLA was only to demonstrate how one can get principles to support any conclusion. My post wasn't to discuss the merits of static finder methods in Active Record, for example, vs. a Repository in DDD."

This is true but your post made fairly derogatory comments on repository while many bolsterring comments for the AR/rocky's comments.

More to the point ... I am putting forward a case that repository should be used as it is a very small investment and if you go down the other road you will have no clear method of refactorring if you need what repository would have given you to start with. I like to look at such things as cost vs risk. The example given includes a very small cost but a huge risk ... I would rather eat the small expense up front than have a large (undetermined) risk at the tail end that would likely have me saying "this can't be done" ...

A perfect example of this would be if later you decide you need to do something your OR mapper can't do using a pattern such as AR. A refactor to the repository pattern at this point would be a huge change (quite likely large enough that it would be deemed not possible) as it effects not only the domain but every client of the domain.

The more important point is about the risk management side of the decision to go a given route. If adding a factory now costs me 5 minutes (even though it is not very necessary though it could be in the future) and the alternative refactor will dribble out into 72 client applications at a later point, risk management would say to provide the factory up front.

David Hayden points out one of my pet peeves.