A Rails directory tree that expresses DDD layers and bounded contexts.

ddd-rails-tree.txt

components/
  my_bounded_context/
    app/
      presentation/      # This is called the "UI" layer in DDD literature, but it is also 
                         # where things like JSON interfaces live -- any kind of presentation 
                         # or handshake to anything outside. So "presentation" rather than "ui".
        assets/
        helpers/
        mailers/
        views/
      operation/         # Would be named "application" if we weren't already in an "app" directory
        controllers/
        listeners/       # Wisper plumbing. These should traffic in Domain Events.
        services/        # Application services, as distinct from domain services. 
                         # http://gorodinski.com/blog/2012/04/14/services-in-domain-driven-design-ddd/
        workers/         # Thin Sidekiq shells that delegate to domain services.
      domain/
        my_bounded_context/
          my_first_aggregate/
            repository.rb
            my_first_aggregate_root_entity_name.rb
            another_entity_in_this_aggregate.rb
            an_event_about_this_stuff.rb
            value_object_only_in_this_aggregate.rb
            a_relevant_factory.rb
            a_relevant_service.rb
          another_aggregate/
            repository.rb
            another_aggregate_root_entity_name.rb
            second_entity_in_this_other_aggregate.rb
            another_event.rb
          a_domain_topic_that_is_not_an_aggregate/
            a_service_here.rb
            perhaps_an_event.rb
            and_a_value_object.rb
      infrastructure/
        persistence/     # ActiveRecords
                         # This will frequently get broken out as its own component 
                         # that depends on the domain.
          my_bounded_context/
            whatever_record.rb
            whatever_record_repository.rb     # gets registered as the provider for the domain repository
        # TODO what else in infrastructure? I'm not clear on how anything other than persistence is 
        # distinguished from application ("operations") logic. 
        # Perhaps simply promote persistence a level instead?

@replaid Rails provides a 20kg sledgehammer and we're etching glass. A very neat trick when you can pull that off more than once. The tools, however, do not tilt the odds in your favour. One of my favourite quotes from Nick Sutterer's Trailblazer book is

For every Rails project, there is exactly two outcomes. Either someone in the team’s an experienced architect and leads the software to an advanced design with service layer, view components, maybe forms, and so on. Or, and that’s the classy way, the project strictly follows the Rails Way and will end up as a code disaster.

Having and heeding an architect is no guarantee of avoidance of disaster, but the converse is as reliably true as death and taxes. Or, as I've been putting it half a dozen times over the last two years, when your architect/lead developer/chief engineer puts double-digit percentages of her or his effort into mitigating Rails, let alone my current more than half, you have an existential threat to the success of your project, wrapped beautifully in what you've sold yourself and your other stakeholders as the solution to your project.

I don't think we're in Kansas anymore, Toto. The sky is falling.