[LRUG] [Blog post] (Rails) Application directories named as architectural patterns antipattern

Thu Sep 10 09:48:55 PDT 2015

I've worked on projects split by domain and those split by pattern. When I
come back a year later, the ones that remain the best organised are those
split by pattern.

The reason is that there are always edge cases, objects that don't really
fit a specific domain. Where do I put a password_recovery_service for
example. Do I nest it under user or create a password domain? One year
later I have to try and remember my decision. I also have to trust that
other developers have stuck to the domain model I invented on the spur of
the moment.

Patterns on the other hand remain constant.

On 10 September 2015 at 17:36, Enrico Teotti <enrico.teotti at gmail.com>
wrote:

> @Jhon
>
> 1) Why is it ok to end up with a directories for Controllers, Views and
> Helpers?
>
> I say it's ok only because the framework sets that as a convention. If you
> use those conventional directories in different contexts namespacing and
> gems are necessary.
>
> 2) Sometimes you are creating classes that fulfil specific roles within
> the framework; e.g, Presenters. How do identify their function when they
> aren’t grouped in a directory?
>
> Sometime the classname has that suffix ie. ValidReservationPresenter.
>
>
>
> @mark
>
> As application complexity grow moving away from AR conventions
> (ie. validation and relationships) is a must. I like your db namespace
> approach, sometime I think of AR as a repository so you could use that
> keyword.
>
> > gradually introduce this kind of structure as appropriate.
>
> Agreed that on a small app this approach can be unnecessary, but I've
> rarely seen an app staying small so knowing when to introduce is very
> important. I hope my article gave that insight.
>
>
> On Wed, Sep 9, 2015 at 5:20 AM, Mark Burns <markthedeveloper at gmail.com>
> wrote:
> > This is an approach that has worked well for me on a couple of projects.
> > I think I gave up on fighting rails about where to put the views and the
> > controllers, and had a mix of approaches. I.e. only moving towards this
> > approach for the obvious cases.
> > Where there is a clear grouping of a large enough bunch of related items
> > e.g. DictionaryEntry, DictionaryEntryPresenter, DictionaryEntryCreation,
> > etc. then it makes it easier to navigate and fits in well with the
> concept
> > of connaissance.
> >
> > It does lend well to namespacing, which then leads nicely into separating
> > into engines. And in one case, for an unused area of functionality it
> was a
> > surprising case of
> > rm -rf dictionary_entry specs/dictionary_entry
> >
> > Run the specs and everything still works. Feature removed! (Then just
> > quietly remove the views and controllers/routes afterwards).
> >
> > Didn't have time to look into getting that aspect smoothly done. But I
> would
> > probably better spend that time looking at trailblazer, which seems to
> have
> > a lot of great concepts in it.
> >
> > Along these lines, I quite enjoy the concept of keeping the spec close to
> > the implementation as golang does. I've only gone as far as domain
> concept
> > based folders in the spec folder as mentioned. I'd be interested to hear
> if
> > anyone has had success with a directory listing that looks like this:
> >
> > dictionary_entry.rb
> > dictionary_entry_spec.rb
> >
> >
> > The only fiddly issue apart from the views/controllers folders was with
> AR
> > and namespacing based on the domain concept. Which would traditionally be
> > the ActiveRecord model name.
> > E.g. rather than pollute a DictionaryEntry AR model with tons of
> classes, I
> > ended up namespacing all my AR models as Db::DictionaryEntry etc.
> > Which when you have lots of objects in an app serves a dual purpose of
> > hinting which one is the thing that writes to the db. Probably a
> > double-edged sword, hungarian notation anybody?
> >
> > But equally, on a small app, with a few presenters, a few controllers and
> > non-obvious groupings then it is overkill. It doesn't really cost much
> more
> > to gradually introduce this kind of structure as appropriate.
> >
> > On Wed, Sep 9, 2015 at 5:59 PM <jc at panagile.com> wrote:
> >>
> >> Hi Enrico,
> >>
> >> Thanks for sharing this. It’s an approach that I agree with in general -
> >> I’d much rather classes were grouped by domain than by pattern. I have
> got a
> >> couple of questions though:
> >>
> >> 1) Why is it ok to end up with a directories for Controllers, Views and
> >> Helpers?
> >>
> >> 2) Sometimes you are creating classes that fulfil specific roles within
> >> the framework; e.g, Presenters. How do identify their function when they
> >> aren’t grouped in a directory?
> >>
> >> (Or maybe my assumtion at the start of the second question is wrong, in
> >> which case I’d like to hear why.)
> >>
> >> Thanks,
> >> John
> >>
> >>
> >>
> >> On Tue, Sep 8, 2015 at 5:43 PM, Enrico Teotti <enrico.teotti at gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I wrote a blog post on (Rails) application directories named as
> >>> architectural patterns and suggesting a more intention revealing
> >>> alternative:
> >>>
> >>>
> >>>
> http://teotti.com/application-directories-named-as-architectural-patterns-antipattern/
> >>>
> >>> Ciao,
> >>>
> >>> Enrico
> >>>
> >>> --
> >>> [skype] enrico.teotti
> >>> [web] http://teotti.com
> >>> [twitter] agenteo
> >>> _______________________________________________
> >>> Chat mailing list
> >>> Chat at lists.lrug.org
> >>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> >>> Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> >>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >>
> >>
> >> _______________________________________________
> >> Chat mailing list
> >> Chat at lists.lrug.org
> >> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> >> Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> >> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
> >
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> > Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
>
>
>
> --
> [skype] enrico.teotti
> [web] http://teotti.com
> [twitter] agenteo
>
>
> --
> [skype] enrico.teotti
> [web] http://teotti.com
> [twitter] agenteo
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150910/01f52a24/attachment-0003.html>