Is DDD still relevant?

I heard someone mentioning Eric Evans and DDD (Domain Driven Design) a few times and so I decided to see what’s its all about. It took me a while to get through the book, partly because I’m a slow reader, partly because the book is long and partly because the read is dry. As I was working through the book, I often wondered to myself: “is this still relevant?”.

Lots of described techniques are common place in everyday software development, however some of them evolved, for example: Microservice. It represents a bounded-context and due to the nature of a microservice, it is separated and doesn’t share objects or internals. Translators, entities, value objects and aggregates are fairly standard on projects I’ve been in so far. Layered architecture, frameworks, team work, supplier-consumer team relations, managers, refactoring and ivory tower architects are fascinating subjects, but again been there and done that. I’m not a history buff but I do enjoy it and so I find myself smiling reading through some parts, lets not forget the book is almost 20 years old. I did find an answer to one lurking question I had for a while: “why less capable engineers tend to accumulate in a legacy but still important, core software systems?” and let me say, Eric nailed it.

So some techniques might be dated but in my mind still relevant, however all of it is just peripheral stuff. What about the core? What about domain? Well this is where things get muddy for me. As I read through examples and discussions, I understood the value of good design, born in ubiquitous language, with help of business specialists, capable fearless engineers with commitment to deep thinking and forever deepening understanding of a business model. In theory DDD is the best thing that can ever happen on a project, however in reality (and by some degree of the author’s own admissions and disclaimers), DDD is not always the best choice or even a possibility. In my mind too many things must align in order for DDD to happen and bare fruit. In any system with many moving parts, there are things that can and typically will go wrong, especially when we are talking about creative work and human operated system.

But is the book still relevant? I think so, I would not be putting it on the top of “must read before programming”, but it still be on the list. I’m sure that commitment to deep thinking and modelling will not be going away any time soon. On top of it, perhaps as an industry we are no long bounded by monolith, but bounded-context is here to stay in one form or another.

In a nutshell:
-: long, dry read
-/+: relevance of some ideas in present software development
+: methodology to design and implementation
+: covers lots of aspects of system development
+: plenty of discussions
=: the book is good, I think people aspiring to be or current architects will reap lots of benefits. Few things feel dated but lots is still very much applicable and valuable. There are lots of books and materials that hold (IMHO) more value for developers in early and middle stages of learning the craft. But at some point Domain Driven Design should be considered.

Title: Domain-Driven Design: Tackling Complexity in the Heart of Software
Author: Eric Evans
Cover:

Domain-Driven Design by Evans Eric

I took few notes during the read:

Domain-Driven-Design-notesDownload

Angular RxJS unsubscribe as a feature design

After few hours of thinking and more hours of implementation, I finally proved my idea is workable. I found it be a bit intriguing and so let me share it. Before jumping to the matter at hand, I would like to briefly mention that:

  • I don’t believe in end-2-end testing
  • I prefer unit testing
  • I like to test-drive my code

A few more details can be found here. On top of the above, I dislike using mocks, spies, stubs and other fakes to make testing “easier”. Now don’t get me wrong I do use mocks a bit, but mostly at a boundary (calls to backend, db and such). Let’s be reasonable, if code is a mess and/or legacy or there is a time constraint, options tend to dwindle and if you have to mock, you mock.

Now let’s see about my situation: I have simple app with navigation bar, located at the very top of the screen and top of the component hierarchy. The navigation bar contains search component. Below I have the main space with a router that happily swaps out different main components, depending where you click.

There is no simple way to pass data from the search component to presently displaying main component, unless we use observable, in particular Subject observable. So we have search observable and a main component is subscribed to it. The question is: “how do we test unsubscribe in the main component when we navigate away and the main component is destroyed?”.

After some thinking, I realized that NOT every main component is searchable, in those cases search component can be hidden. The approach has elegance to it, since it will help with testing and at the same time enhance user experience by eliminating confusing search feature that doesn’t seem to do anything when non-searchable main component is displayed.

On the other hand, when main component is searchable, then search component must be displayed so user can search it.

Ok, so how do we go about killing two rabbits with one bullet? We will enhance the search observable so it will count how many subscribers it has. Whenever any main component subscribes or unsubscribes to the search observable, the count will go up or down. Next a bit of elbow grease to wire up search component to hide/show when the count is equals to or less than 1 and we are done.

The whole logic can be tested by checking if the search component is displayed or hidden via jasmine spec, by navigating between main searchable components and main non-searchable components. No mocks, no spies, just elegant, user friendly feature and code design.

Decade with Accent

It seems the human mind likes round numbers – 10 year, a decade, all sound important. So here am I trying to grasp that it has been a decade since I bought my Hyundai Accent. Without any doubt it has been a journey, the car has seen a lot and I believe it is a good time for some thoughts.

Recently, I’ve re-read my reasoning to “why accent”, and at this point I wouldn’t be jumping the gun by saying: “I was right”. The vehicle got 241,702 kilometres on the odometer and never left me on the side of the road. Granted, I have always taken good care of the car and did proactive maintenance – complete log. It also doesn’t cost much to change out all fluids and filters earlier than needed, therefore the results are impressive – the car has plenty of life left in it. In addition, since it is a small car with small displacement, the amount of fluids required is also relatively small. Therefore buying high quality fluids is not a big deal. I remember after the purchase, my mechanic said: “this car will go for 300,000 kilometres easy” – back then I thought it was just wishful thinking, but now it seems more like a reality. The car is quite impressive in the reliability and repairability regard. I think one reason people don’t like cheap cars is because of perception: “cheap will break, but expensive cars will last”. Unfortunately, this is not the case.

Recently I was reading up on Suzuki Jimny just for fun. One thing that stood out like a soar thumb is technology in the latest release of Jimny – by 2018 standards, it is hopelessly outdated. Even the most cheapest vehicles on the market had direct injection for a while now but Jimny doesn’t. So perhaps cost of the direct injection is not a factor, so why would any automotive engineer pass-up an opportunity to make engine more powerful and efficient? I believe the reasoning is: old technology is simple and proven by time. Jimny at its core is dead simple, rugged and the most reliable thing you can through into the wilderness. Let me make it very clear – old technology is not pretty on paper – fuel economy sucks, power output is embarrassing and the rest you don’t even want to see. But on the flip side, it is dead simple, accessible, and reliable vehicle that will work for a very long time.

Coming back to my Accent, the concept of reliability is the same as with Jimny – old, but simple and simple means reliable and cheap to fix. Now I’m not saying let’s stay with port injection and 4 valves per cylinder forever and ever. What I’m saying is that as new technology comes out and is fitted into expensive vehicles first, where it is being tested in the real world. By the time it trickles down to the cheapest of the bunch, the technology has been fairly tested, and so cheap vehicles receive proven tech.

Now 3 years ago I said that next car will be either another Accent or Miata. Well I bought a Miata which opened up my mind to such a different experience. Driving anything after Miata feels very dull, I believe Miata ruined my driving experience of any other car. Miata entrenched my opinion: either get a car that makes you feel good or simply don’t bother – get the cheapest. Nowadays when I drive Accent, I simply appreciate it as a simple transportation. I guess I would compare the experience to getting on a personal bus and slowly rolling to a destination, nothing more or less. Back in the day I often thought about upgrading, modifying and otherwise changing the character of my Accent, to give it more bite, more edge, more driving “feeling”. Well I’m happy I didn’t go for that. Accent is a car with its own character and when you buying one, it is imperative you understand what it is, then you will not be disappointed.

P.S: “If I needed personal transportation I would buy Accent again”, but unfortunately it is no longer an option in Canada. Hyundai stopped selling the Accent.

Everything passes, this too will pass

King Solomon

Goodbye TDK SoundCube

It is funny how things workout and sometimes don’t workout in life. A few years ago, I participated in a hackathon, it was a very interesting experience amplified by the front-center seat that I have taken. The experience primarily taught me one thing: no plan survives contact with a customer ( my version of the famous ). The same idea is applicable to many situations, mainly because planning and reality tend to diverge at least at one point.

So here, I’m 8 years after purchasing my “ultimate” speaker and the speaker is no longer with me, I sold it a few days back. Why am I thinking about it? For one, I have been a bit philosophical lately – life does not stand still, everything changes, customer’s mind moves on and ultimately nothing remains the same. Another reason is sunk cost bias – I spent time and money looking for the “ultimate” speaker and it didn’t make it past 8 years with me… I feel like there should be some kind of thought consolidation, lesson learned, so here I am.

Why did I part ways? Simply because I didn’t use it. In the last 4 years, I turned on the speaker probably less than a dozen times. My life has changed, I have a child, I live in a house and music time switched from late evenings to early mornings when I sit quietly and work on things. Playing music loud is out of the question and over the last few years I stopped enjoying loud music – aging is no fun. Since priorities have changed and the speaker was collecting dust, it was an appropriate time to make a decision: to cling to the past or to let go and move forward, I chose the latter.

Leaving things behind is not an easy thing (at least for me). I get attached to certain things, I let them define me in part. However, leaving things behind is a part of life – which needs to be examined, learned and practiced. Like any exercise it has its benefits – clearing mind, space and allowing for new things/experiences to flow in.

Well, it is time to say thank you for the experience and bring joy to the new owners, bye SoundCube.