small medium large xlarge

Me_pragsmall
06 Dec 2011, 00:35
Richard Michael (6 posts)

In Chapter 9 on message queues and asynchronous components, there are two places I felt the example code could be improved, partly for readability and partly to reflect the domain language.

On p161, in the Account class, the instance variable holding the transaction queue is named “@queue”, but “@transaction_queue” would be better (similar to “@balance_store = BalanceStore.new”).

In fact, the following section (p164, “Building the TransactionProcessor”) does indeed name the instance in that way, “transaction_queue = TransactionQueue.new”.

More extensively, on p162, in the section “Building the TransactionQueue”, “messages” would be better referring to “transactions” ; in keeping with a ubiquitous domain language.

For example, the filesystem directory should not be named “messages”, but rather “transactions” ; and the “write(transaction)” and “read()” methods are similarly more clear as:

def write(transaction)
  File.open("transactions/#{@next_id}", 'w') { |f| f.puts(transaction) }
  @next_id += 1
end

def read
  next_transaction_file = Dir['transactions/*'].first
  return unless next_transaction_file
  yield File.read(next_transaction_file)
  FileUtils.rm_rf(next_transaction_file)
end
Avatar_pragsmall
06 Dec 2011, 23:33
Matt Wynne (92 posts)

These are fair points Richard, but I’m afraid it’s too close to our deadline for me to start making changes like this to the code. The risk is that it would drift out of sync with the text somewhere, so I’m going to leave this one. Thanks for pointing it out though.

In my own opinion, the places I’d like to rename code in the worked example are the World extension module names. @KnowsTheDomain@ is a bit of a silly name, for example. I wish I’d chosen @AutomatesTheDomain@ but for similar reasons it’s too late to change it now!

You must be logged in to comment