I watched the battle from the sidelines where Jimmy Bogard talked about how not to do “poor man’s dependency injection”.  Then Tim Barcz gave his input.  Then Chad Myers got into the mix. Considering this blog is called Inversion of Control Freak, I should probably add my $.02 now that things have settled down.

I’ve gone back and forth on this issue where I really want to allow flexible wire-up of my components using the IoC container of choice, but at the same time, I’d like to have the ability to just skip the wire-up and have a default, ready-to-go implementation.   In other words, I want all the power and flexibility and all the convenience at the same time.  I want my cake and I want to eat it too!

Rinat Abdullin, co-creator of the coolest IoC container Autofac, had a good idea that I had kicked around in his most recent blog post.  Previous to reading his post, I had considered just creating a simple, default factory class that would do the default wire-ups and go from there.  Rinat, in his article, said the following (about 2/3 the way down the page) regarding the creation of a factory method:

By the way, that’s a good approach for creating developer-friendly libraries. We implement all functionality as separated and decoupled components (as in component-driven development) ready to be consumed by whatever IoC Container the developer likes. Extensibility and flexibility come in there natively.

Should the project be too simple for wring up the proper IoC infrastructure, developer-friendly library will have some static factory [method] to use. This class would serve as a logical entry-point into the library and would host hard-coded creation of components (using recommended configurations and settings).

There’s the answer.  Just create a simple factory method.  Those that want to swap default implementations can do so using constructor-based injection, while those that just want to use the library without all of the fuss can do so as well.

As I look back at applications and systems that I have been involved with over the years, what strikes me is how data-centric those applications were.  In fact, the driving force behind most of those applications was the data.  The behavior of an application was looked at as merely if statements and for loops.  It was inconsequential.  The other thing that strikes me about all of these applications is that, because they were all about the data, they were incredibly dumb.  Literally.  The applications didn’t “think” for themselves.  The “logic” governing new data was a purely technical consequence littered with database queries and web service calls, etc.

In the real world, this would be similar to viewing a human as an inanimate object—like a rock.  In a data-centric mindset, it’s all about the properties of the thing you’re dealing with, e.g., the name, size, weight, color, shape, etc.  In the case of the rock and human, you get the data you want and continue.  This is why a data-centric view is flawed when complexity merits a behavioral view.

In the case of the rock, it just sits there and doesn’t do anything, just like the dumb, data container that it is.  You do everything to it.  But when you interact with a person in real life, the person can understand and work out problems on their own in a behavioral fashion.  You can’t see their thought processes, you simply feed in sensory information (messages to be consumed through the senses) and the person behaves and interacts with his/her environment (publishes messages).  The person has no getters/setters.  You simply provide a command and the person decides if he/she wants to respond.  (As an aside, I think we should refer to all behavior objects as females.)

How does this apply in DDDD?  Simple.  You give an object new information to consider.  It internalizes the information and when it receives a “command” (a request to perform some action), it decides how it wants to respond based upon the sum total of the object’s experience during its lifetime.  In other words, all of the data that you have ever provided to the object constitutes the object’s experience and understanding and it behaves and makes decisions (publishes a message) based upon that collective experience.

In a nutshell, that’s the power behind behavioral programming.  It’s a very Tell, Don’t Ask style in which your objects get the job done, rather than you doing everything.  And if you don’t like what an particular object is doing?  Send it out to pasture and put something else in its place.

I just spent the last six hours in the debugger going through some legacy code because of some problems we had in a production system.  Okay, maybe the code is only a few years old, but it doesn’t have any tests in it whatsoever, which is what makes it legacy code.

The most common argument against TDD (and testing in general) is that it takes too much time.  That’s a half truth because it does take time.  But considering the ripple effect that two edge conditions had in some of our production code today and the hours spent isolating, understanding, and fixing the bugs, I would consider a few extra minutes of upfront TDD investment well worth the price.  That was time that I could have been spending writing more code or expanding business capabilities instead of chasing down a bug.

I think the biggest reasons so many are hesitant to get do any kind of automated tests are threefold:

1. We get our head down and we start programming away and we don’t even want to think about writing tests and killing the momentum.
2. Writing tests is hard because we have to think more.  If anything, this should be an incentive rather than a deterrent because we’re thinking about the problem from different angles and our comprehension of the problem increases.
3. We don’t understand how and when to use state-based testing and interaction-based testing, nor do we know the difference.

On #3, I try as hard as I can to make everything a state-based test.  One technique is to use a fully encapsulated domain model.  My technique is a little different than what Udi outlines in his blog, but the principle remains.

In the end, as professionals and craftsman that care about our code, we should be writing tests not only for ourselves, but for those that follow us.

While fixing a few bugs in some legacy code that had no tests didn’t follow DDD principles, I had an epiphany.  Well, maybe I shouldn’t say it that way.  I had a few concepts reinforced in my mind regarding the importance of state-based testing, specifically using Behavior-Driven Design techniques.

The problems I had were related to business concepts, such as renewing a customer’s subscription.  Other than the bugs that I fixed, the main problem with the code was that it didn’t follow DDD principles.  There were no aggregates or entities.  Everything was a service, yet the complexity merited a domain model. Yuck.

With a fully encapsulated domain model, you simply have an aggregate.  You feed the aggregate events and it publishes events.  It’s as simple as that.  No properties and other methods to call other than Consume where an event is fed into the aggregate.

By having a fully encapsulated model, we find that CQS, BDD, and DDD can intersect in a powerful way.  Specifically, if all I can feed the aggregate are messages and all it publishes are messages, everything becomes a state-based test, which then facilitates a BDD style.  For example:

Given: A series of events that put the aggregate into a known state.

When: Event XYZ occurs:

Then: Events ABC and 123 are published.

In a real world scenario:

Given: Your account is overdrawn.

When: WithdrawFunds

Then: NonSufficientFunds

Greg mentioned this exact scenario in a message on Yahoo Groups a few months back.  After reading that post, I created this blog entry as an empty draft.  Encountering those bugs today, which the above scenario would have solved, gave me the opportunity to finish this post.

Not long ago I was at the home of Stephen Covey, author of The 7 Habits.  It was a real pleasure to meet him and rub shoulders for a few minutes.  He was welcoming and gracious and very insightful when he spoke to you.

You can tell a lot about a person from their home.  When I first walked into his house, I noticed the large mosaic in the tile floor of a compass pointing north.  In addition, I didn’t see any TVs in his house.  But the main focal point at the center of his home, with large windows overlooking the valley, was a living area and a library.  I decided to see what his library was like.

His library wasn’t necessarily large, it was probably about 20 feet square with a vaulted ceiling about 15 feet overhead.  It had a fireplace and a soft couch in the middle, and one of those ladders that goes around the perimeter in order to access all of the books.  At the center of his collection he had volumes and volumes of classic and inspiring pieces of literature.  He also had inspiring quotes written on the walls that, as he said, would take you on a journey of self discovery.

As I was looking over his collection of books, I noticed something.  I didn’t seen any of his books—the books that he wrote.  I wanted to ask him, but then I saw them.  They were piled into a haphazard little stack on the floor in the far corner.  I should have taken a picture but I didn’t.  I just thought it was funny.

I responded to a message on Yahoo! Groups DDD forum regarding locking an aggregate root and serializing access to it.  The question surrounds locking of an aggregate while it processes a message.  The concern was that “pessimistic locking” makes your system unable to scale, which per the formal definition is absolutely correct.  But there’s a slightly different way to lock that isn’t truly pessimistic.

Below follows my response to some of the concerns posted in the above message.

> Well I don’t agree with this – at least in our domain. There are many
> commands that could be applied simultaneously to the one Aggregate.
> That’s what an IConflictWith interface would be for – for those that
> do actually conflict. For large aggregates in a shared-nothing
> architecture, it just wouldn’t scale to only allow one message at a
> time.

From what I understand and have read, IConflictWith is used for conflicts between your eventually consistent reporting store and your aggregates.  The idea is that because you’re issuing commands built off of eventually consistent (potentially outdated) data you need a way to determine if the incoming command might conflict with other changes that have already occurred within the aggregate.  No amount of locking could prevent this when using an eventually consistent model.  Yet, we need to ensure each aggregate is always be 100% fully consistent at all times.

Going back to the locking strategy, one of the critical elements in DDDD is that because an aggregate root must be 100% consistent at all times, it can only be actively receiving commands in a single process/address space at a time.  In other words, you wouldn’t want to have the same aggregate running on multiple machines at the same time and have both actively receiving and processing commands.  [Greg has an active/passive aggregate mechanism to handle fast, graceful failover scenarios.]

If an aggregate can only exist in one address space at a time, how do you scale?  Don’t you create a bottleneck?  Yes and no.  You scale through partitioning.  You distribute your bounded context across multiple machines where Machine A handles aggregates with IDs A-C, Machine B handles aggregates with IDs D-F, etc.

Okay, but we’re still locking the aggregate and a single message to the aggregate could take a really long time to process.  The answer then is, don’t lock for a long time.  But what if you have to?  If you have some message that’s taking a long time to process, the processing for that message probably needs to be broken out into a service.  Then, when you need the service, you send a message to it and ask it to perform some work.  You then release the lock on the aggregate.  When the service completes, it sends a message letting you know the work is done and the status of the work (or whatever you need), you lock the aggregate, process that message and release.

In other words, the lock on the aggregate is always for an extremely short amount of time–never more than a few milliseconds.  The aggregate receives the message, makes a quick decision based on any and all the information it already has, and sends a message.  If the aggregate needs more information to make a decision, it sends a message asking for more information from a service, the user, etc.  You never *ever* lock the aggregate while it’s “waiting” for a “response” from the service, doing so would kill your scalability.

My primary resources for understanding and guidance in DDDD come from various parts of books that are available, many of which Greg has suggested:

• Domain-Driven Design
• Enterprise Integration Patterns
• Pattern Oriented Software Architecture
• Distributed Event-Based Systems
• among others

Greg Young has consolidated much of this information and has been presenting it in a fairly high-level form at various professional conferences during the last few years.

I just found another good resource discussing some aspects of DDDD.  Gojko Adzic posted a video of him giving a presentation entitled DDD in a Distributed World.  I haven’t yet watched it in it’s entirety, but he’s got a summary version of it in text from as well as the slides posted on his blog.  Check it out.