Hi John Koisch, thank you for your feedback.
That’s actually true, ActiveRecord has already a lot of abstractions and well implemented APIs. It decouples DB context from us and that’s great. That is its purpose I guess.

It’s not about durability for the long run. I strongly believe that putting away the persistence layer from your mind and concentrating on your logic would yield to better domain modeling.

What I don’t like to be more concrete in applications that I’ve seen so far is the following:

SomeEntity < ActiveRecord::Base  def do_something
# buru buru...
save <=============== this one
end
end

I won’t mention the callbacks which are a different story. You can also argue that you can go one layer up and pass it to the caller:

class SomeDomainService
def call
# buru buru again
some_entity.save
end
end

Completely valid for CRUD applications but it still couples persistence responsibilities to the domain entities. I don’t say that ActiveRecord is bad or something. It’s a great library that we should take advantage of and we all do.

I’ve been struggling a lot on what a service object is and not? What a domain entity is and not. Active Record just adds another layer to put you far away from that concern. At least in my opinion.

I plan to write a series of articles on how to write an application without persistence in mind actually. Mostly based in DDD practices and I hope to have a better example there.

Best
LP

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store