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

Enrico Teotti enrico.teotti at gmail.com
Fri Sep 11 08:29:02 PDT 2015 

Hi Nicolas,

Thanks for your contribution, I believe many developers feel like you and
there was a time I did too.

I believe the pattern approach is ok in very small projects. Like Mark
pointed out knowing when to diverge is critical, personally I never work on
projects that stay small which is why I use the context approach from the
start.


First I am gonna address your concern about classes that do not fit in any
context.

I'd ask where is that password_tecovery_service used? I doubt from
the billing portion of your app. One solution I used in the past was
creating a shared component and have whichever portion (gem/engine) need it
depend on it. If that's truly just one file that escape your contexts I do
think it's ok for it to stay in the main application.

You say one year later you'd forget where the class lives.

The boundary should map your business model, finding those boundaries
require time and communication with a product owner familiar with the
domain. This is a much harder job then dumping all your files in models and
services but it yields a much better result in the medium to long term and
I struggle to believe a services directory with 60 files using an
unknown number of other class/files from other directories is easier to
understand then a single directory/module encapsulating that functionality.


In regards to developers ignoring your model.

That is a big problem. Developer diligence is a must or it's pointless to
have a domain model. In my experience if the concept is explained right
devs are onboard, especially after they worked on a big ball of mud. If
they aren't maybe they should tackle smaller challenges.



In the end the conventional Rails way doesn't force us to think about those
contexts but they are there and ignoring them with "that's not the Rails
way" is a bit silly and results in a big ball of mud project that will need
to be rescued months after it starts.

I'd like others to benefit from this conversations so feel free to ask
questions here or via the blog comments.

On Thursday, 10 September 2015, Nicholas Johnson <me at nicholasjohnson.com>
wrote:

> 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/20150911/235c7bbf/attachment-0003.html>

More information about the Chat mailing list