Have you ever worked on a project where you'd be insanely productive in the beginning but your productivity would take a hit as more features were added?
I used to find myself wondering what was I doing wrong which would lead to thoughts like maybe i'm not talented enough or my problem solving skills are not up to par. I know, sounds depressing right?
My first instinct was to read up on Design Patterns. I started with the Head First Design Patterns along with this Youtube Series on the same and they helped me out a lot. I would think about my code a lot and I would find myself thinking of ways to refactor my code to make it more acceptable by my standards at that time. I also read up on principles like DRY , KISS and YAGNI . But, something still did not feel right
as I would almost always end up adding code complexity; primarily because I did not properly understand the design patterns I implemented and hence did not realize when I should not have used a specific design pattern but part of it was something entirely else which I would later come to know is called Transaction Script
The Click Moment for me was when I heard about Domain Driven Design or DDD. By this point, I had already read Clean Code by Uncle Bob and Refactoring by Martin Fowler. I parsed through Eric Evan's Domain-Driven Design: Tackling Complexity in the Heart of Software and the concepts/ideas he presented just made a lot of sense to me. This was the beginning of my journey of learning to use Domain Driven Design to map any given problem domain to maintainable and scalable code that I wouldn't hate two months after I wrote it. More on this later..
This is a crosspost from my blog
Top comments (0)