Introduction

How many times you saw a Pull Request with hundreds of lines changed only because other developer on the team had differently configured formatting in his IDE? How many times you had to scratch your hear around what is actual value from given pull request and what is just reformatting spacing from four spaces to tab? We have all been there, an apparently simple problem which should be solved once, so we could focus on bringing actual business value often transforms into never ending back and forth battle on how, when and if formatting and syntax validation should be part of automation and once for all forgotten.

After 7 years as a Software Engineer, I always tried to pursue every opportunity to the fullest.

Introduction

I believe every developer working with technologies such as Java or Kotlin had to deal with databases and implementation of specific interaction layer with at some point in their career. Usually probably the most common tool which firstly comes to mind is JDBC - Java Database Connectivity Driver. It is a standard API for connecting to relational databases and executing SQL queries. This is usually the first layer (the closest to database), then we have usually some kind of abstraction layer on top of it, which is responsible for translating database records into objects and vice versa. This layer is usually implemented using ORM (Object-Relational Mapping) libraries like Hibernate, JPA, Ebean etc. Going even further, in ecosystems where we would use Spring Framework, we could use Spring Data JPA which under the hood uses Hibernate but hides its complexity behind simple interfaces and annotations.

Foreword

Introduction

Upon recently re-reading Clean Architecture by Robert C. Martin I went through whole Part III where different design principles are discussed. Although I found all of them interestingly described when it comes to applicability in wider scope than usually they are discussed (mostly SOLID principles), I believe author put a lot of attention to one specific principle which stands for “D” in SOLID and is described as “Dependency Inversion Principle” (DIP shortly).