Udi Dahan is known as the "Software Simplist". What does he mean by simple? Is he saying that software cannot be used to tackle complex problems? Or does he mean that we work at a problem until a simple, clean, and concise solution presents itself? And what about "the simplest thing that could possibly work"? Here are a few of my favorite quotes regarding simplicity:
"I wouldn't give a fig for the simplicity on this side of complexity; I would give my right arm for the simplicity on the far side of complexity" ~ Attributed to Oliver Wendell Holmes Jr. »
[UPDATE: This post was written about the time Greg Young formally named his CQS architectural implementation of command query separation. Because of the change in terminology this post was written with the understanding that CQRS consisted of all elements commonly associated with CQRS. In other words, CQRS herein is incorrectly defined as the following concepts together: DDD, event sourcing, domain events, true "CQRS", and eventual consistency. It should be noted that all of those concepts better fit under the umbrella of " »
In a former life, I wouldn't think twice about using dependency injection to put behavior into a domain object. But the more I learned about traditional DDD, the more I found that it was considered "taboo" to inject things into your entity objects. Obviously injecting behavior into domain services was okay, but entities were special. Of course, this topic is still a matter of debate among DDDers and there are people on both sides of the line. »
I am a big fan of "the simplest thing that could possibly work". The elegance and simplicity of the following code is hard to overstate:
public static Func Now = () = DateTime.Now
It's wonderful because there are no external dependencies, no external libraries, and no versioning issues. Furthermore, we've placed a layer of indirection such that we can easily substitute calls to DateTime.[Utc]Now as necessary.
The only problem with this code is that it works at a single layer. »
In my previous post, I talked about a technique that I saw for testing time and also about how I simply injected some kind of ISystemTime/IClock interface. The problem with that was having to do injection at every level—including domain entities.
Oren Eini's method, while probably the most simple and easiest to implement (both of which are *good things*) has two small issues:
Implicit disposability. You have to remember to reset the static lambda expression every time it's set. »
[UPDATE: I have created an open source library based upon the concepts found below.]
In my early experience with DDD, I loved injecting dependencies into my domain entities. I have since repented. The one downright nasty dependency that we could never quite slip away from was…time. That's right, temporal couplings. Well, not exactly. Instead, we had to couple to an object that provides the current time.
Initially we had used a "TimeService", basically just a service that you would inject (ugh) into your entities so that they could query the current time. »
In a few of Greg's video presentations regarding DDDD, he mentions using a circular, disk-backed buffer. As far as I can tell, he's using this as a temporary storage mechanism when events are committed. He then has a single consumer reading the events from this buffer and putting them into the permanent event store.
I just read an interesting article by one of the .NET CLR guys about building a thread-safe, producer/consumer buffer. »
One critical difference between Git submodules and Subversion "externals" is the concept that submodules are locked to a particular commit. Normally this is a "good thing" because blindly attaching yourself to a particular branch in Subversion can have interesting an unexpected consequences when the branch changes out from underneath you. Subversion provides a way to "lock" to a particular revision via the "-r" parameter in the svn:externals declaration, e.g."name –r commit_url" »
About a year ago, I read Continuous Integration: Improving Software Quality and Reducing Risk. It's a great book that talks about the importance of making your CI server the hub of development.
One part of the book that was very insightful was the exact role of build scripts. Specifically, the build scripts should be able to execute on our developer machines as well as the CI server. Even though we were attempting to do this to some extent, there were some additional advantages that were obtained by going the rest of the way. »
With permission, here is our general CI workflow document that my team drafted that governs our vision regarding how we do CI:
Continuous Integration Workflow
Abstract
We want to provide developers with the ability to make changes to project source code and to then automatically, transparently, and consistently subject all project source code to rigorous testing and quality assurance processes.
Further, we want the build artifacts resulting from source code changes to be quickly available to interested parties at a well-known location, but at a lower level of confidence in the those changes. »