Ubiquitous Language can be refactored!

2007-05-15T18:05:21Z

Recognize that a change in UbiquitousLanguage is a change to the model.

Excerpted from DomainDrivenDesignBook.

We all understand the importance of ubiquitous language as the basis of communication amongst the stakeholders of a project. Often we have had modeling sessions with the business team when we talk UL, yet in the back of our minds we might not like the terms that are being used to describe various entities/value objects/aggregates/services etc in our discussion. Most often than not, we may have resigned to the terms as permanent; sometimes we might not even care. Alright, the point that I am trying to make is that if the domain model equates to code and TDD practitioners seldom think twice before refactoring code (we call it courage bundled with the abilities of Resharper); so why do we hesitate to change the UL?

The UL gets created when the first code is written. It grows as the code grows and gets dirty as more and more crap (no pun intended) gets added to it. And yet, we sometimes undergo massive code refactoring exercises without thinking too much about how that will impact the model. And if its changing the model, its bound to have an affect on UL.

There is always that potential that our model and UL might have a mismatch and I believe every effort should be made to not let that happen.

Self-Documenting Unit Tests

2007-04-10T16:49:00Z

We have been practicing agile for more than a few years now and getting better as we move along, or at least that's the goal and a desired expectation from the team; rightfully so since humans typically learn from experience. We jumped on the notion that by going agile, we can certainly reduce the mostly obsolete documents that managers/developers strive to keep current (or not), and fail. So the idea of having self documented code and unit tests sounded encouraging, to say the least.

The inspiration for this blog entry is not to comment about the want of having comments within code, since there is unquestionably no need, even though that's a very hot unresolved topic. A very personal opinion, and I agree with folks out there, for having code comments is when you would like to proudly apologize for your work. "I so am superciliously sorry for writing this code, since I and only I can read it, lest you shall read the comments that I wrote".

The inspiration for this blog entry is really to better understand how we can write self-documenting code, and very specifically the unit tests. We should take pride in the fact that new developers on the team are easily be brought on board to the design of the system merely by taking a look at the unit tests. In an ideal situation that may be the case, however in reality it's more far fetched than it seems. I personally got baffled last week when I started to delve into a feature of our system developed a few months ago. We have strived to keep our unit tests clean and readable, more so functional. The unit/feature/system design obtained by practicing TDD certainly would make all the sense having known the context under which it was established. The context is what defines the behavior of the system, it is what goes on to be gloriously enbraced by the domain model and it is what helps determine the overall design of a system. Best practices of appropriately naming variables, methods, classes etc. are all part of establishing a clear context, which in turn provides clarity and the most needed self-documentation.

In comes BDD or Behavior Driven Design and suddenly there is light, literally shone on the context. As my colleague Joe O talks in his post, and Scott Bellware exhibits the BDD Extension Methods in Orcas that he has been playing with, and the industry in general, behavior as expressed by context has become the most focussed aspect of writing software, more importantly the unit tests and everything follows suit.

I firmly believe that "comments within code" issue can never be resolved, however for those like me who would rather write simpler code BDD is the way to go.

Jazzlog

Ubiquitous Language can be refactored!

Self-Documenting Unit Tests