Obviously the answer to the titular question is yes.

I have recently found myself questioning whether the logic I am coding belongs in a domain service or in the presenter. I actually found the same logic in the presenter residing the base repository. Something definitely smells wrong, almost like the putrid smell of death, lol, nah just a DRY smell and a hint of mixed responsibility odor. The presenter was calling the Repository directly which was kinda of an indicator, but it is valid to do so, depending on the scenario.

The application that I am currently working in is a web application. That being said, I feel it is valid to consider the web limitations part of the current domain, not just a concern of the presentation. If we need to move to a windows app or something else, it will take a lot of refactoring, so why not just view the web’s issues as part of what affects the domain. Besides, is the purpose of the domain to be abstract enough to support multiple platforms or to dimish complexity? Anyway, that’s another discussion altogether, and I’m digressing.

Here’s the skinny, that’s a valid colloquialism isn’t it. I found string to integer conversion happening in two different places. Once in the presenter, grabbing a string Id from the view, converting it, calling an overloaded GetById method from the repository or throwing an exception if the Id was invalid. The overloaded GetById method was in the base repository, it either accepted a string Id or integer Id, if the string Id was invalid it was throwing an exception. Yikes, this is scary, and to think I was the one that coded all this, frightening, I know. I am recovering so don’t you worry yourself. Now to the current code:

Code to be Refactored:

Presenter

public virtual void InitializeView()
{
	if(TreatmentIdIsValid())
		LoadTreatment();
	else
		throw new ApplicationException(string.Format("A Record of Waste cannot be completed because of the invalid treatment id: {0}", View.TreatmentId));
}

private bool TreatmentIdIsValid()
{
	int validTreatmentId; 

	bool treatmentIdIsValid = int.TryParse(View.TreatmentId, out validTreatmentId); 

	if(treatmentIdIsValid)
		CurrentTreatmentId = id; 

	return treatmentIdIsValid;
} 

protected virtual void LoadTreatment()
{
	try
	{
		CurrentTreatment = Repository<ITreatmentRepository>.GetById(CurrentTreatmentId);
	}
	catch
	{
		throw new ApplicationException("Could not retrieve the specified treatment");
	}
}

Base Repository

public virtual Entity GetById(string id)
{
	int parsedId;

	if (!int.TryParse(id, out parsedId))
		throw new ApplicationException("Could not convert the given id: " + id + " into an integer");

	return GetById(parsedId);
}

public virtual Entity GetById(int id)
{
	return Session.Get<Entity>(id);
}

I think that there is no place for logic in the repository it should be left to the domain service. You could even argue that this functionality is common and can be moved to a domain utility. For ease I am going to move it to a domain service. Now, lettuce see the refactoring to the code above:

Refactored Code:

Presenter

public virtual void InitializeView()
{
	LoadTreatment();
}

protected virtual void LoadTreatment()
{
	CurrentTreatment = RecordOfWasteService.GetParentTreatmentById(CurrentTreatmentId);
}

Domain Service

public virtual Treatment GetParentTreatmentById(string id)
{
	int validTreatmentId;

	if (!int.TryParse(id, out validTreatmentId))
		throw new ApplicationException("Could not convert the given treatment id: " + id + " into an integer");

	return GetParentTreatmentById(validTreatmentId);
}

protected virtual Treatment GetParentTreatmentById(int treatmentId)
{
	try
	{
		CurrentTreatment = Repository<ITreatmentRepository>.GetById(treatmentId);
	}
	catch
	{
		throw new ApplicationException("Could not retrieve the specified treatment");
	}
}

Base Repository

public virtual Entity GetById(int id)
{
	return Session.Get<Entity>(id);
}

Alrighty then, we got any logic out of the repository, I’m feeling better already, my face has gone from grimace to grin, and no not the McDonlad’s character Grimace. Super serial, a la Al Gore about ManBearPig, what was Grimace, was he what you turn in to if you only eat McDonalds and nothing else?

The responsibility of the repository should be to read and write to persistence/web services/messages etc. The string validation logic is in the domain service, I may pull it out to a base service or utility service. Our presenter is so much simpler now, and not worried about logic that it shouldn’t have to worry about. Hmm, the cleanliness is delightful. There is no more duplication of logic in the presenter and repository, w00t! Now let me know your thoughts, comments, opinions etc. of dissent or agreement, it will help me and hopefully others learn and grow. I’m off to watch the some Teenage Mutant Ninja Turtle original series, wow, I’m a nerd.

I have been recently sumo wrestling with the idea of entity validation in my mind. So far, the validation problem, which is like, E. Honda, has the advantage over my mind which is currently like, Chun Li. The worst thing is all the other thoughts in my head are constantly struggling against my entity validation thoughts. As Homer Simpson says, “Every time I learn something new, it pushes some old stuff out of my brain”. Except for me E. Honda is doing his grab move, where he squeezes his opponent between his fat, and squeezing all of my current thoughts out of my brain. I don’t understand how sumo wrestling evolved as a sport, do they really have nothing to do in Japan. I bet it was the master creation of some drunken emperor. Umm, let’s see I want to watch two super fat dudes wearing nothing but a diaper try to knock each other out of circle with their bellies, muahahaha, they’ll be playing this sport for centuries!

Ideation:

I have been pondering about the idea of validation. Dictionary.com says valid is: “sound; just; well-founded, producing the desired result; effective”. Wiktionary’s valid definition in terms of logic is:“A formula or system that evaluates to true regardless of the input values.” When we think of validation in a programmers state of mind, the definition of valid in the logical sense, seems to jive the best. If x == y then it is valid if x != y it is invalid.

Entity validation is determined by business rules and processes. It appears that there are two fundamental approaches to validation, proactive and reactive validation.

Reactive Validation:

The most common way I have seen validation handled is the addition of an IsValid state to the entity. A good way of implementing this approach can be found in a posting by Jimmy Bogard. Whenever a business rule or process is broken the entity is no longer in a valid state. Then the user is informed of the problem in a different layer of the application. This form of validation is a very reactive way of handling validation. Meaning that it waits until something bad happens and then performs a function to cope with the contaminated actions. I don’t like this reactionary response, I would rather use something more preventative.

Proactive Validation:

What is valid validation? I wonder how many times I can use the word valid, or one of its etymological children in this post? What is a valid number of uses? I think the answer is 42.

So, is valid validation a proactive or reactive approach? I believe that proactive is always the best approach. My definition of proactive entity validation is never allowing an invalid entity to exist. This means removing the concept of an IsValid state on the entity. Once that is removed you don’t have to do an IsValid check everywhere in the application, which is my main gripe with the reactive solution. Is it valid for your domain to ever contain an entity in an invalid state, something about this scenario makes my skin crawl and stomach churn, or maybe it has to do with something I ate last night. Hmm, it was spicy so maybe. An invalid entity just seems like a bad idea, it is a treacherous force that will actively work against you like Saruman’s voice being cast across middle earth. I think being proactive is a much cleaner approach, and will cleanse your domain of IsValid checks. Wow, that is just a proof less rant.

Now the question is, what’s the best way to implement such a proactive solution? That’s the E. Honda I have been wrestling with. Let’s go over the broad definition of proactive entity validation. An entity cannot be created if it does not meet the business rules. Once we have a valid entity it cannot be modified unless the modifications satisfy the business rules. The stumbling block arises when your entity’s validity is based on a certain context. For example, it is valid to have a physicians drug order without a signature. When the process requires that the order to be sent to the pharmacy, the order is only valid when it has a signature. Ah, now the proactive solution becomes tricky because valid is defined by context. Following the proactive approach I could not create the entity without a signature, because it would be an entity in an invalid state. The only solution that I have thought of to this is having a drug order without the signature and a drug order request that inherits drug order and has the signature. The pharmacy then receives that drug order request with the signature on it.

Outro:

I have not yet fully fleshed out the details of how exactly this would be implemented. I hope to hammer out a spike with a spiked drink. I do believe that using a proactive approach to entity validation falls more in line with domain driven design by having a tighter coupling to the business language. A drug order does not need a signature to exist. A drug order request with a signature fulfills the need of the drug order being sent to the pharmacy.

Be a proactionary and not a reactionary.

My pondering stems from a song (which hereby refers to a Twitter discussion, eh, why not?). This song was started by a tweet from one of my co-workers earlier today.

First a bit of background, I have been able to glean the key purpose(s) of Domain Driven Design from my co-workers and from researching it a bit here and there. Unfortunately, I have not been able to sit down and read through Eric Evans’ Domain Driven Design book. So, you might say that I am some what of a novice when it comes to domain driven design. One might say my knowledge of it, is fairly infantile, but they would be mediocrates.

I have learned are that DDD is a different mode of thinking about software. Analyzing the context of the business process you are reproducing with software and then translating that into the design said software. You come up with things like the Ubiquitous Language to better serve the need to replicate the targeted processes. That being said a lot of it seems to be logical conclusions that one would arrive at through thought, trial and error over an amount of time.

One of the key ideas that I took away from my gander into DDD, was that validation should happen at the domain level. I have been wrestling with this idea in my mind for a week or two. The wrestling began when I read a posting on Anemic domain models and subsequently read Martin Fowler’s original posting on the subject. After absorbing that information a light bulb ignited in my noggin, pretty much the whole domain model of the project I am currently working on satisfies the classic definition of an anemic domain model, i.e. classes containing only properties with getters and setters. Yikes! I realized that we had been doing everything wrong, all of our business logic was in our presenters. Well, there is no time to go back and correct everything at the moment. I have been striving to get away from this bad habit with our latest feature and it just so happens that today that along came a Twitter song regarding domain validation and more abstractly, anemic domain models.

My co-worker had a wonderful question about defensive coding / unit testing and a statement regarding domain validation:

@derickbailey:
“Q: should I do defensive unit testing / coding immediately, or wait until someone finds a bug to do the defensive coding?”
“i’m sold on “model / view / presenter / presentation model” idea at this point. presentation model contains input validation”
“example:’make sure i have a valid date time, not an empty string’. would you call that business rules? “

My overall response was yes, it is definitely worth defensive coding / unit testing, if you wait for the bug to crop up in the UI, it will be much more expensive to fix, which is expressed by Scott Bellware’s latest posting. There were also some other various tweets about the difference between UI validation and validation in the domain. Validation as business constraints not processes.

Derick’s question/statement led to this response from Bellware:

@Bellware:
“why are business rules and input validation not the same?”

Next, Bellware went into some abstract ideas that were relevant to the topic at hand, but went over my head completely. It seems he enjoys doing this regularly , but thats just my musings. Anyway, he and Derick were discussing the abstractions, then Bellware stated some things to me about DDD:

@Bellware:
“what if the only domain is the domain that creates the need for that validation?”
“if it’s all you need to deal with, then you don’t need anything more elaborate”
“a domain that isn’t built for a specific context is pure technical masturbation. it earns you demerit points, not promotions.”

Bellware’s statements got the Grey matter churning in my head. At first, I was thinking of domain and context synonymously in my head, but then he clarified it for me. Context refers to such things as a web application, an operating system application, hardware driver etc. Derick’s example of getting a date from a string can be viewed as strictly a concern when dealing with a web interface(context). Is Bellware proposing a domain should be geared towards a specific interface implementation? If a domain is not aimed at a specific context then is it a fruitless effort in self indulgence?

Well, now I am stuck in an endless loop pondering my perceptions of DDD. It would probably be prudent to invest some time reading Eric Evans’ Domain Driven Design, to get a better grasp on the tennents of DDD and the reasoning behind them. I’m sure I will gain more understanding in time from research and mulling these ideas over in my head.

As a side note, this song has proven to me the usefulness of a tool such as Twitter. I was somewhat skeptical of it at first, and had passed it off as another mundane social networking tool used to gratify the cravings of narcissists. It seems it can be used for good and evil.