Skip to content
A sample Domain Driven Design project using Ruby on Rails ❤️
Ruby
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
app/layers Improving the documentation May 5, 2018
bin Initial Commit Apr 17, 2018
config Including CQRS query side May 5, 2018
db Including CQRS query side May 5, 2018
lib add endpoint and seeds May 4, 2018
log Initial Commit Apr 17, 2018
public Initial Commit Apr 17, 2018
spec Initial Commit Apr 17, 2018
tmp Initial Commit Apr 17, 2018
vendor Initial Commit Apr 17, 2018
.env.development Initial Commit Apr 17, 2018
.env.test Initial Commit Apr 17, 2018
.gitignore update gitignore Apr 17, 2018
.rspec Initial Commit Apr 17, 2018
.ruby-gemset change gemset name along with repository May 4, 2018
.ruby-version Initial Commit Apr 17, 2018
Gemfile add endpoint and seeds May 4, 2018
Gemfile.lock add endpoint and seeds May 4, 2018
LICENSE Updating license May 5, 2018
README.md Update README.md Jul 26, 2019
Rakefile Initial Commit Apr 17, 2018
config.ru Initial Commit Apr 17, 2018

README.md

What is this project?

DDD Rails Sample is a open-source project meant to be used as a start point, or an inspiration, for those who want to build Domain Driven Design applications in Ruby. As Rails is the most robust web framework in Ruby community we tried to use it in a way we could modularize the layers and decouple responsabilities. This project is the result of this efforts.

NOTE: This is NOT intended to be a definitive solution or a production ready project

Technologies/frameworks involved

  • Ruby on Rails
  • Active Record
  • Dry::Types
  • Dry::Validations

Architecture

  • Object oriented programming following SOLID and Clean Code principles
  • Domain Driven Design
  • Repository Pattern
  • CQRS (same database)
    • Commands
    • Queries

Nice to have in the future

  • Include different Bounded Contexts
  • Domain Events
  • IoC Container or Service Locator
  • Domain Notifications instead of raising exceptions
  • Event Sourcing
  • A simple front-end implementation

Setup

bundle install
rails db:create
rails db:migrate
rails db:seed
rails s

Different implementation versions

This project describes a two-phase implementation of the Repository pattern. The first implementation (version 1) is somewhat more pragmatic as the domain class itself inherit from Active Record. In the second one (version 2) we evolve this implementation in a way that our domain model became PORO classes, but that came with a cost as you can see in more details below.

Version 1

In this version we treat te Persistence Model and Domain Model as the same thing. We use this in the first version because it is a way more simple, fast, and we can have take advantage from all benefits the ORM offers.

ORM + DDD dilemma: You can see more details about the tradeoffs and the risks of using the Persistence Model and Domain Models as the same thing or in a separated way in this SO answer.

The only problem with Active Record is that, different from other ORMs like SQLAlchemy (Python), Hibernate (Java), Entity Framework (.NET), you can't create an external class to map your domain model to the database. In Active Record your class MUST inherit from ActiveRecord::Base in order to be persisted. This breaks (💩) the Clean Architecture but as mentioned above, its a tradeoff that you may want to pay in face to the pragmatism.

Version 2

... More details soon ...

About

The DDD Rails Sample was developed by Murilo Capanema and Fabrício Rissetto under the WTFPL license.

Contributions are welcome 💓

You can’t perform that action at this time.