An entity is identified by an identifier, while value objects are identified by their value. If I make a living renting cars to tourists, I might not care the least about the identity of the colors the cars came in. I just care about their value; Rosso Corsa, Azurro Metallic… If I repaint the car, the color changes, and the previous color is abandoned as a whole. However, if I were a car paint manufacturer, I would care a great deal about the identity of a color. My first action might be to make up a marketable name for the color, something that I can identify it with - a la Burnt Sienna or Iceberg Blue. The color might have a certain structure from the get-go, but I might experiment with the structure along the way, while I’m still referring to it as the same color. ...

When you use knockout validation to extend observables with validation rules, it will add a few functions to these observables - the most important ones being; error and isValid. You can use these functions to verify if any of the validation rules were violated, and to extract an error message. To extract all of the error messages out of a composite model, you can use a grouping function. function BookingModel() { var self = this; self.contact = new ContactModel(); self.departure = new DepartureModel(); self.isValid = function() { return self.contact.isValid() && self.departure.isValid(); }; self.validate = function() { if (!self.isValid()) { var errors = ko.validation.group(self); errors.showAllMessages(); return false; } return true; }; } function DepartureModel() { this.street = ko.observable('').extend({ required: true }); this.houseNumber = ko.observable('').extend({ required: true }); this.city = ko.observable('').extend({ required: true }); this.time = ko.observable('').extend({ required: true }); this.isValid = function() { return this.street.isValid() && this.houseNumber.isValid() && this.city.isValid() && this.time.isValid(); }; } function ContactModel() { this.firstName = ko.observable('').extend({ required: true }); this.lastName = ko.observable('').extend({ required: true }); this.phoneNumber = this.firstName = ko.observable('').extend({ required: true }); this.email = ko.observable('').extend({ required: true }); this.isValid = function() { return this.firstName.isValid() && this.lastName.isValid() && this.phoneNumber.isValid() && this.email.isValid(); }; } This is what my first attempt looked like. A little later I discovered that you can get rid of these boilerplate functions on the composite model by applying the validatedObservable function instead. ...

This is the second and last part of my notes I scribbled down attending the IDDD Tour. The first part was published last week. A better model Even if you come up with a better model, the fact that it has been the ubiquitous language of the domain for decades proves that it works for them. This quote bothers me a bit. There definitely is truth to this, but modeling an existing process often presents such a great opportunity to revise and improve it. Naked models don’t conceal deficiencies, inefficiencies and aberrations. Exploring alternative models free of habituation, politics and legacy is dirt cheap, while the outcome could considerably benefit all. It seems such a shame not to take advantage of this. As with most things, know when to pick your fights. ...

Two weeks ago I got to spend four days attending the IDDD Tour by Vaughn Vernon. Although my book queue has only allowed me to shallowly browse the book, I had high hopes for this course. I anticipated a week of getting lectured on DDD with a few practical exercises, but was blown away by the openness and interaction promoted by Vaughn and his associate Alberto Brandolini. A passionate group, engaging workshops, long days and lots of sharing made these few days exceptionally satisfying and inspirational. I’m grateful to those who got this show on the road; it was more than worth your trouble. ...

The first year I wrote software for a living I spent my days mostly writing forms over data applications; most of my efforts were wasted just trying to make things work using ASP.NET and the Webforms engine. It was only after a year and graduating from the School of Hard Knocks that I learned there is a lot more to building clean and maintainable software than knowing the ins’ and outs’ of a proprietary UI technology. ...

I’ve been doing some work lately which involves sequentially reading large files (> 2 to 5GB). This entails that it’s not an option to read the whole structure in memory; it’s more reliable to process the file in chunks. I occasionally come across legacy that solves exactly this problem, but in a procedural way, resulting in tangled spaghetti. To be honest, the first piece of software I ever wrote in a professional setting also went at it in the wrong way. ...

Two weeks ago, I shared my first impressions of IronMQ. Last week, I looked at some infrastructure to facilitate pulling from IronMQ. This implementation worked, but I hadn’t put it under stress yet; “First make it work, then make it fast”, and all of that. I arranged a simple scenario for testing: one message type - thus one queue, where there are eight queue consumers that simultaneously pull messages from that queue, and dispatch them to a handler which sleeps for one second. ...

I wrote about using IronMQ as a cloud-based message queue last week. In that post I explained that you can go at using IronMQ in two ways; either you pull from the queue yourself, or you let IronMQ push messages from the queue to your HTTP endpoints. At first sight, the latter allows you to outsource more infrastructure to their side, but upon closer inspection it also introduces other concerns: security, local debugging and scalability. ...

First time I touched messaging was in the first few years of my professional life working on software that supported fire departments in their day-to-day activities. The dispatching software would send messages to a proprietary broker, which in its turn would forward them to interested subscribers; other dispatching clients, or services. To ensure availability, the broker component could failover to a different machine, but that was about it. It didn’t allow you to queue or retry messages; if you weren’t up when the messages were forwarded, you would never receive them. When the brokers were both down, all messages would be lost; the clients didn’t have infrastructure out-of-the-box that could queue the messages locally until it came back up again. When things went haywire, and they occasionally did, these missing features would often leave us with an inconsistent state. More modern messaging software has solved these concerns though. ...

Somewhere over a year and a half ago I discovered the music of Dire Straits, which has sparked a fanatical love and fascination for the guitar in me, and basically for every piece of music Mark Knopfler has ever touched (*). A year ago, I finally had the courage to pick up the guitar myself. Not sure if I’d stick with it, I made an uninformed purchase of a rather inexpensive Squier Jazzmaster, just because it somewhat resembled the real object of desire, a Fender Stratocaster. Three months ago, I got rid of the Jazzmaster, and bought myself a tango red Mexican Stratocaster, and I’m in love with it. Yet, I have also become very fond of the sound of a Les Paul these days. Having just bought the Strat, I thought I could maybe find a cheap used Les Paul online. ...