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

Sat Sep 12 05:42:18 PDT 2015

As an advocate of DDD I'd also recommend partitioning your app by context (or aggregate) rather than design pattern. This seems more intuitive to me and I think it makes it easier to reason about the significant components of your system.

That being said, I don't think it matters hugely and as long as things are organised and easy to find, it should be fine.

> On 11 Sep 2015, at 4:29 pm, Enrico Teotti <enrico.teotti at gmail.com> wrote:
> 
> 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
> _______________________________________________
> 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/20150912/6fdfd923/attachment.html>