Tag Archives: ddd

I’m starting to hate the Repository pattern

What we supposedly use the Repository pattern for?

  • For querying the model?
  • For CRUD operations?
  • To have work with entities like they were already loaded in memory?
  • To not depend on underlying technologies like ORMs?

Pure junk! All those arguments could live in the 2000s, but they are now absolutely outdated!!

I’m done with that pattern. It doesn’t offer a **** and instead of this, it just adds complexity and a bunch of classes and interfaces that restrict your queries to a poor set. It’s OK that you can write your own methods in a custom repository, but as you do, it loses its maintainability and it can really get riddled with tenths of methods for each kind of query you want to get (and this really gets worse when you have to retrieve lots of different DTOs).

So, forget about this pattern if you’re getting data access seriously and start researching on new ways to do MORE, not the same or less.

Use an ORM! and don’t wrap it! if you do, you’re losing your precious time. Do you think that a change in the Database will not affect you if you wrap, and wrap, and wrap it again? HA! In the best of cases you will end up having to design 200 DTOs and 1000 different methods to access the database in a “decoupled” way.

So if you try to make an onion, good luck!


DDD principles in a visual designer? Part 1

Yeah, boys, I’m crazy to think about applying DDD to an application like this, but I feel that being so purist has some great consequences to my designs, taking some benefits from this way of thinking  about development.

Domain-driven design, taking as it sounds, is to put the focus on the domain. Think about the domain and about how the model HAS TO BE. Let the rest flow as you need it. Everything should be subsidiary (although it will be important, too).   Take the true essence of the domain of it and make a model.

That model can be simple or incredibly complex, but you have a model and you can talk about it using concepts and relations that flow naturally from it. The model is self-contained and has to describe any substantial change of the domain it represents. You can talk about it as a whole!

That’s really cool.

But there are situations where the model is a bit strange. What if the model is not a common entity like a Person, a Bank Account or a Product? What if you have to deal with entities that are commonly attached to the UI, the layout or part of a document, like a Paragraph, a Rectangle, a Field…?