Khalil Stemmler - SOLID: The Software Design and Architecture Handbook

It all started with How would you design your business-logic layer?

Right after I graduated from University, I started the process of interviewing for jobs.

I read and practiced all of the basic interview questions, studied Cracking The Coding Interview, and made sure I knew my stuff on algorithms, data structures, JavaScript, and its language quirks. I went over tons of things I havent had to think about for a long time, like closures, IIFEs, passing by reference vs. value, etc.

Most of the interviews went pretty well. I did interviews at several startups and a couple larger companies. Yet, it was when an interview for a Full-Stack JavaScript job at a popular AI startup that a cog in my mind irreversibly activated.

The recruiter for that role told me to really know my stuff on AI and Python (which, as a Node.js developer, I admit I didnt know enough about), so I spent the majority of my time cramming knowledge about AI and popular Python libraries, attempting to appear as if I knew something about that space.

After getting through the first round of interviews and getting invited for a second technical interview, I felt like I had it in the bag.

The interview was going smooth right up until my interviewer asked, how do you design your business-logic layer?

Thats the question that started everything for me.

It was as if he was asking me to speak another language. I hadnt the slightest idea of how to answer it.

I just recited what I knew about MVC (model-view-controller), but as the words were leaving my mouth, I was realizing more and more that nothing about MVC really screamed business-logic.

Safe to say, I didnt get the job. My recruiter even dropped me. But it was that moment I realized there was an entire world of software design and architecture that I needed to teach myself. That failure and inadequacy made me really interested to learn the answers.

At the end of that hiring cycle, I ended up in a job as a Frontend Consultant. I was mostly looking for a low-stress job I could perform to hack my career and expedite my learning by:

• purchasing and studying as many books on software design, patterns, and architecture as possible
• and applying everything I learned from those books to improve my cumbersome ~300k-line Node.js startup app

Every evening after work for 8 months, I read books and wrote code.

I started from the basics. Reviewing everything I knew about Object-Oriented Programming, making sure I really understood the concepts I learned in school, but probably never internalized (abstract classes, the 4 principles of object-oriented programming).

I browsed the internet, writing down all of the terms and concepts that Ive heard of but never really cared to try to understand (POJOs, dependency injection, dependency inversion, inversion of control, concrete classes, design patterns, etc.)

Then I moved over to Architecture.

I didnt get too far without studying basic UML relationships again. This is what most of the literature about architecture and software design utilizes to express ideas. After getting familiar with that stuff again, I went started looking into things like:

• Coupling
• Cohesion
• Managing dependencies
• Separation of concerns
• Layered / onion / clean architectures / ports & adapters
• Conways law
• Use-case driven development
• Packaging large applications in modules
• TDD
• and the SOLID principles.

The point where it all really felt like it paid off was when I discovered Domain-Driven Design. My learning approach was to learn by doing in addition to teaching others (which is why my blog exists today).

Over those 8 months, a lot happened. I quit my job, refactored Univjobs codebase to Domain-Driven Design, made considerable improvements to the codebases maintainability, flexibility, and reliability and have been passionately attempting to share what Ive learned with my peers online @ khalilstemmler.com.

Those books cost me a lot of money though. Among the purchased were Clean Architecture, Clean Code, Domain-Driven Design, Implementing Domain-Driven Design, The Clean Coder, Refactoring, Patterns of Enterprise Application Architecture, etc. I easily spent over $1000 on books.

But now, if you were to ask me how would you design your business-logic layer, Id have a lot to say WORTH IT.

Design problems occur more frequently than algorithmic ones

In our daily programming jobs, were more often required to:

• name things well so that theyre understood and can be found
• structure things well so that they can be understood and changed
• change things quickly

If you went to school for Computer Science, youd probably remember focusing a lot on mathematics and algorithms.

For many (myself included), these were some of the hardest courses during my undergrad.

The first week of my second year at Brock University, taking Advanced Data Structure and Algorithms, the welcome back assignment was to build a LISP interpreter using Java.

The assignment had a prerequisite knowledge of linked-lists, queues, stacks, and other ADTs. I remember sitting down to solve that programming assignment on a Friday night in my basement apartment. My parents had just come to drop off some food, and my roommate left to visit his family for the weekend.

The Sunday night, my roommate returned, and I asked me, have you left that spot since Friday?. I realized that I actually hadnt. Id been sitting in the same spot for 3 days working on the solution to the problem. Eventually, I solved the challenge, handed it in, and got a decent grade.

I attribute my success to solving this problem to pure brute force.

While there is a lot of value in studying mathematics and practicing algorithms, the magnitude of algorithms that we typically encounter in our daily programming lives looks more like this:

That code simply sorts a hashtable of job templates alphabetically.

Underwhelmed?

That covers 95% of the complex code youll end up writing as a web developer.

Although the type of industry youre working in and the domain youre writing code in does have an influence on the just how often youll be crafting algorithms, in most web applications, theyre relatively simple.

If only there was a course in university that taught you how to consistently provide value to a business without writing unmaintainable code.

Another reason you should study software design and architecture is:

Over ~$85 billion was spent fixing bad code in 2018

I wrote an article all about this remarkable phenomenon and where I believe it originated. The executive summary is:

• Developers arent being taught the essential software design skills
• Most companies practice agile
• Practicing agile means changing and refactoring code
• To refactor code, we need tests
• To write tests, we need to know how to write testable code
• Most developers cant write testable code, which results in productivity plummeting

The truth is, not a lot has changed about the fundamentals of software design over the past 20 years, but theres a