OJ Develops

In part 1 of this series , I talked about the pains that I and my colleagues have experienced when working in code bases that used N-tier data-centric architectures. In this post, I will detail one approach which has allowed me to escape that madness. Lasagna Code We've all heard the term "spaghetti code". But there's also "lasagna code": "The object-oriented version of spaghetti code is, of course, 'lasagna code'. Too many layers." - Roberto Waltman — Programming Wisdom (@CodeWisdom) February 24, 2018 I use that statement to remind myself that layers can sometimes do more harm than good. That also reflects my experience. Of course, it's not really the number of layers that's the problem, but rather, how the dependencies between those layers are set up and what abstractions those layers represent. Consider this familiar diagram of a data-centric N-tier architecture: Or even a diagram of a DDD-inspired but sti...

You've seen it before. You have been tasked to make a seemingly simple change on a web page. Add a couple of fields, perhaps. Or add new functionality, but still CRUD-like in nature. "Piece of cake," you say. You then proceed to make a change to the HTML. Then to the viewmodel. Then to the business logic layer, which I will also call service layer. Then to the repository layer. Then to the database. (You could also do it in reverse.) All those steps just to add a couple of fields. Which is kind of okay, maybe no big deal. But, as the infomercial says, "Wait, there's more!" Exhibit A: Implementing Functionality Involving Multiple Entities Before we immerse ourselves in the madness, let's set up the domain: an online retail site. In your database, there are Product and Order tables, which have a many-to-many relationship between them. You are following a data-centric N-tier architecture, and therefore there is a repository layer with classes su...