September 18, 2018 / by Indu Alagarsamy / In DDD /
The Captain of the Night Watch
This article was originally published in Domain-Driven Design: The first 15 years ebook.
This article is based on a conversation that ensued during a midnight stroll in the streets of Amsterdam with Eric Evans, Paul Rayner, and Mathias Verraes.
There I was, standing in front of a masterpiece, thanking my lucky stars of the incredible opportunity that I had just been given to be there, to be present in that moment. I was in front of Rembrandt’s Night Watch, standing in complete awe. The captain was striking and regal. The light flowed into the room, as if the heavens were trying to illustrate his authority. He was giving orders to the people around him. There was a sense of life and belonging, a canvas that was filled with so much emotion all captured so beautifully. I was in the midst of it all, facing the captain and for a brief moment, it almost felt as if he was walking straight toward me.
Ever since I first saw the windmills of Zaanse Schans in a travel book, I was fascinated and wanted to visit Amsterdam someday. So I was beyond thrilled when Mathias invited me to speak at DDD Europe 2018, and the venue was Amsterdam! The universe had granted my wish. Not wanting to waste a single minute, I started my exploration of the city with the Rijksmuseum. When I arrived at the museum, I realized that I had only about an hour, so I asked the museum attendant what’s the one thing I shouldn’t miss at the museum. Non-judgmentally she said, “Rembrandt’s Night Watch.” And that’s how I first met the captain on a complete coincidence.
Fast-forward to the conference. Despite my jet lag, my talk at DDD Europe went fabulously well, and at the conference closing, I was invited to go to dinner and hang out with the DDD greats: Eric Evans, Paul Rayner, and Mathias Verraes. I felt incredibly lucky. At dinner, we discussed Bollywood movies, and I was pleasantly surprised listening to Eric talk about “Lagaan” and explain the storyline to Paul and Mathias.
As we were making our way back to our hotel we found ourselves in front of the Rembrandt statue at the city square. Rembrandt was standing on a pedestal and right below him, it was as though his painting had come alive at the stroke of midnight. All the characters that Rembrandt had meticulously detailed out in his Night Watch were transformed into bronze statues and brought to life in 3D. There were 22 statues including one for the dog, all standing in the same pose created by Rembrandt, frozen in time for the world to see. And there was the captain again. It felt like deja vu standing face to face with him, this time in 3D.
What does this have to do with Bounded Contexts?
We took a selfie in front of the statues. But then Eric suggested that it’s not every day you get to see what’s behind the Night Watch, something you don’t actually get to see in the actual painting and that we should be taking pictures from the other side. This brought up the question of different perspectives. Because the statues were 3D, you had a different view, a perspective from behind the figures as well. As we were taking pictures, being a nerd, I had a serious question. I always have a tendency to try and relate software with actual real life things and that helps me understand the bigger picture. So the question that was burning in me this time, at the midnight hour was: would the front and back of the statues make different bounded contexts since it was essentially a different perspective of the same thing? Do different perspectives make different bounded contexts? It was as if the captain was trying to show me something important, but I had to try hard to grasp it. Luckily for me, I was with the right company, so I asked Eric. Eric with his calm and logical way of explaining things answered me without a second thought that the painting and the sculpture would be the two different bounded contexts and not the front and the back of the captain.
What makes the painting and the sculpture a different context?
I let that sink in for a moment. So the statue and the painting were the different contexts. Then like a puzzle piece falling into place, it started to make sense to me. The biggest reason is because the rules around these contexts were completely different. The constraints of making art on a canvas and sculpting a bronze statue are entirely different. While the captain might appear differently from the front and the back, the constraints on the statue were the same, regardless of which angle you looked at him.
I remembered the evening at the museum where I stood in front of the Night Watch. Light was streaming down on the captain as if to highlight his authority. But at the square, the captain was just one among the 22 individual sculptures. Unless you know about Rembrandt’s Night Watch, you couldn’t tell who was the man with all the authority. At the square there was nothing special about the captain, and definitely no special lighting. The constraints on the light were different in both the painting context and the sculpture context.
When Rembrandt was painting, he didn’t have to worry about how these characters were going to look from behind. 2D was perfectly sufficient. However, when the Russian artists created the sculptures they had to deal with a whole new set of constraints that pertained to creating statues out of bronze in 3D.
In Rembrandt’s art, the level of detail for each character was different. In the painting, the details on the captain were stunning from the wrinkles on his boots to the stitching on his vest and then some of the other characters were vague, for example the dog. The sculptures however were all equally well defined. There was no difference in the amount of detail in the captain’s statue vs. the dog’s statue.
Also, in the painting there is a character hidden in the group, that’s believed to be Rembrandt himself. Whereas at the square, Rembrandt was in plain sight towering over all of his creation from his place on the pedestal. So on the surface, while the art hanging at Rijksmuseum and the sculpture at the city square both represent the Night Watch, they are bound by different constraints, have different goals, and therefore different focus and detail. That makes them different bounded contexts.
How does this help with software design?
In software design, we might have to model the concept of a “Product.” However what the Product is to the “Sales” context is different from that of an “Inventory” context and that of a “Shipping” context. In the Sales context, a product brings in revenue to the company. In the Inventory context, it’s a thing that you have (or don’t have) in some quantity. In the Shipping context, it’s a thing that has some weight associated with it, which gets sent from, say, Amsterdam to California. On the surface, just like the Night Watch, it’s the same. However, depending on the context, the rules are different.
We have been taught early to look for nouns to help determine the objects. , We’ve been so well trained to find the nouns, it’s hard to think differently. In that mindset, a product is a noun; therefore it gets its own model. Things like name, description, price, how much of it you have in stock, what it would take to ship it, etc., tend to get associated with this product object model. OO always stressed behavior and data hiding and data encapsulation. But it’s too easy to turn off that behavior bit part of it and just model based on pure data. But here’s the thing: would you require transactional integrity when trying to update the description of the product, compared to where you were trying to ship it? Are there any business rules to say, “All products that start with X in the name cannot be shipped to California?”. If you don’t have any such rules, then having the product’s name and the shipping rules in the same transactional boundary doesn’t make much sense.
Here is where Eric’s Domain-Driven Design forces you to think of individual models, as opposed to the “one universal model to rule them all”. Placing more emphasis on what processes happen in the business, and focusing more on the pain points, and identifying the constraints, helps to model the context more accurately, rather than just trying to model the data in a entity driven fashion. Properties like Description and Price can be separated from the context if we apply the rule that each context must be isolated, internally consistent, and unambiguous. And most importantly that the context can have the same representation of a concept, just that different rules govern it. Just like Rembrandt’s Night Watch on the canvas and the sculptures in the city square.
As all nights do, this one came to an end too. I felt like I had come a full circle. From that first moment when I was in awe of the Captain at Rijksmuseum to seeing him again at the square, both Rembrandt and Eric in their own ways, showed me the nuances of the bounded context. While I had to part my ways with the captain, I walked away with a new learning and appreciation for Bounded Contexts.