4 ms·

I haven't used Rails before, so I may be missing something, but is this necessarily the case? If I remember correctly the blue book isn't too keen on modelling

I haven't used Rails before, so I may be missing something, but is this necessarily the case? If I remember correctly the blue book isn't too keen on modelling your domain in your database, but rather build it out of POJOs and then build a separate layer. But at the same time it's open to using DDD with a logic paradigm, which is eerily similar to a relational database. If, after you've done the necessary work with the domain experts, you have determined that Rails is the right tool for a job, I think you can safely call it a paradigm and carry on.

berkes 5y ago
I'm quite certain that with some effort, and possibly some stretching of definitions, one can "do DDD with Rails". But at that point you are going against the grain. You are both missing out on some good parts of Rails and spending a lot of time to work around or against what Rails wants and needs: Rails is very opinionated, don't forget that. From https://en.wikipedia.org/wiki/Active_record_pattern#Criticism https://en.wikipedia.org/wiki/Active_record_pattern#Criticis... > Another critique of the active record pattern is that, also due to the strong coupling of database interaction and application logic, an active record object does not follow the single responsibility principle and separation of concerns as opposed to multitier architecture which properly addresses these practices.[citation needed][clarification needed] Because of this, the active record pattern is best and most often employed in simple applications that are all forms-over-data with CRUD functionality, or only as one part of an architecture.[citation needed] Typically that part is data access and why several ORMs implement the active record pattern. And a Rails without ActiveRecord, while technically possible, leaves you with a Rails that is hardly workable -if at all- and brings a lot of pain. Your application will live in ActiveRecord models, spread all over: > ActiveRecord is meant to become the central part of your domain logic. -- https://solnic.codes/2016/05/22/my-time-with-rails-is-up/ https://solnic.codes/2016/05/22/my-time-with-rails-is-up/ So the answer would be: yes, this is necessarily the case. In practice and even in theory.
- Tabular-Iceberg 5y ago
  I can’t speak from experience, but the article you linked seems to make sense. Rails appears to have very little to do with object oriented programming, except as an implementation detail. My point is that although Evans strongly recommends OOP for DDD in the blue book, it’s not a requirement. If the first design phase of DDD, where you sit down with the domain experts, you might discover that what you are building is really just a CRUD app. Then it’s probably wise to actually use a CRUD framework, Rails or otherwise. You’re still using DDD, and you’re not even going against the grain or missing out on framework features. When you make your database your model you delegate “decoupling from persistence” to the authors of your RDBMS. They have already decoupled it for you in that you’re not opening files and writing data, your INSERT statement is just stating facts about your domain. I’ve explored the pattern of putting the entire domain model in the database in the form of constraints, triggers and queries that return JSON. The controllers just map URLs to queries, validate the input and just pass the result of the query to the client without looking at it. It’s extremely powerful and productive. You never have to think about N+1. It’s more like logic programming than anything else. The downside is that SQL and associated tools aren’t terribly ergonomic, and it’s hard to find developers who are comfortable working like that.
  - regularfry 5y ago
    I think part of the point is that if you are a Rails shop first, then trying to strap DDD on is only rarely going to work. If you are a "right tools for the job" shop who decide to do DDD as a primary tool, then there might be cases where it is what you choose.
    - Tabular-Iceberg 5y ago
      Even if you are a Rails shop first, you can use DDD to determine if it's wise to take on the project in the first place. If it turns out that the domain cannot be expressed as a CRUD app, maybe refer the client to someone else. Then you will officially have used Rails with DDD, even if you haven't written a single line of Rails code for the project. Much of DDD is really tech independent, and takes place before a single line of code is written. This is probably also where it's the most important. You're going to have to learn the domain first or the project will be a world of pain regardless of what architecture you choose.

berkes 5y ago

I'm quite certain that with some effort, and possibly some stretching of definitions, one can "do DDD with Rails". But at that point you are going against the grain. You are both missing out on some good parts of Rails and spending a lot of time to work around or against what Rails wants and needs: Rails is very opinionated, don't forget that. From https://en.wikipedia.org/wiki/Active_record_pattern#Criticism https://en.wikipedia.org/wiki/Active_record_pattern#Criticis... > Another critique of the active record pattern is that, also due to the strong coupling of database interaction and application logic, an active record object does not follow the single responsibility principle and separation of concerns as opposed to multitier architecture which properly addresses these practices.[citation needed][clarification needed] Because of this, the active record pattern is best and most often employed in simple applications that are all forms-over-data with CRUD functionality, or only as one part of an architecture.[citation needed] Typically that part is data access and why several ORMs implement the active record pattern. And a Rails without ActiveRecord, while technically possible, leaves you with a Rails that is hardly workable -if at all- and brings a lot of pain. Your application will live in ActiveRecord models, spread all over: > ActiveRecord is meant to become the central part of your domain logic. -- https://solnic.codes/2016/05/22/my-time-with-rails-is-up/ https://solnic.codes/2016/05/22/my-time-with-rails-is-up/ So the answer would be: yes, this is necessarily the case. In practice and even in theory.

Tabular-Iceberg 5y ago
I can’t speak from experience, but the article you linked seems to make sense. Rails appears to have very little to do with object oriented programming, except as an implementation detail. My point is that although Evans strongly recommends OOP for DDD in the blue book, it’s not a requirement. If the first design phase of DDD, where you sit down with the domain experts, you might discover that what you are building is really just a CRUD app. Then it’s probably wise to actually use a CRUD framework, Rails or otherwise. You’re still using DDD, and you’re not even going against the grain or missing out on framework features. When you make your database your model you delegate “decoupling from persistence” to the authors of your RDBMS. They have already decoupled it for you in that you’re not opening files and writing data, your INSERT statement is just stating facts about your domain. I’ve explored the pattern of putting the entire domain model in the database in the form of constraints, triggers and queries that return JSON. The controllers just map URLs to queries, validate the input and just pass the result of the query to the client without looking at it. It’s extremely powerful and productive. You never have to think about N+1. It’s more like logic programming than anything else. The downside is that SQL and associated tools aren’t terribly ergonomic, and it’s hard to find developers who are comfortable working like that.
- regularfry 5y ago
  I think part of the point is that if you are a Rails shop first, then trying to strap DDD on is only rarely going to work. If you are a "right tools for the job" shop who decide to do DDD as a primary tool, then there might be cases where it is what you choose.
  - Tabular-Iceberg 5y ago
    Even if you are a Rails shop first, you can use DDD to determine if it's wise to take on the project in the first place. If it turns out that the domain cannot be expressed as a CRUD app, maybe refer the client to someone else. Then you will officially have used Rails with DDD, even if you haven't written a single line of Rails code for the project. Much of DDD is really tech independent, and takes place before a single line of code is written. This is probably also where it's the most important. You're going to have to learn the domain first or the project will be a world of pain regardless of what architecture you choose.