
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br>On 11 Sep 2015, at 4:29 pm, Enrico Teotti <<a href="mailto:enrico.teotti@gmail.com">enrico.teotti@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hi Nicolas,<div><br></div><div>Thanks for your contribution, I believe many developers feel like you and there was a time I did too. </div><div><br></div><div>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.</div><div><br></div><div><br></div><div>First I am gonna address your concern about classes that do not fit in any context.</div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">I'd ask where is that password_tecovery_service used? I doubt from the billing portion of your app.</span></font> 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.</div><div></div><div><br></div><div>You say one year later you'd forget where the class lives.</div><div><br></div><div>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. </div><div><br></div><div><br></div><div>In regards to developers ignoring your model.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div>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.</div><div><br></div>I'd like others to benefit from this conversations so feel free to ask questions here or via the blog comments.<div><div><br>On Thursday, 10 September 2015, Nicholas Johnson <<a href="mailto:me@nicholasjohnson.com" target="_blank">me@nicholasjohnson.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Patterns on the other hand remain constant.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 September 2015 at 17:36, Enrico Teotti <span dir="ltr"><<a>enrico.teotti@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">@Jhon<span><br>

<br>

1) Why is it ok to end up with a directories for Controllers, Views and Helpers?<br>

<br></span>

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. <span><br>

<br>

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?<br>

<br></span>Sometime the classname has that suffix ie. ValidReservationPresenter. <div><br></div><div><br></div><div><br></div><div>@mark</div><div><br></div><div>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.</div><span><div><br></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">> gradually introduce this kind of structure as appropriate.</span></font><br></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div></span><div>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. </div><div><div><div><br></div><div>

<br>

On Wed, Sep 9, 2015 at 5:20 AM, Mark Burns <<a>markthedeveloper@gmail.com</a>> wrote:<br>

> This is an approach that has worked well for me on a couple of projects.<br>

> I think I gave up on fighting rails about where to put the views and the<br>

> controllers, and had a mix of approaches. I.e. only moving towards this<br>

> approach for the obvious cases.<br>

> Where there is a clear grouping of a large enough bunch of related items<br>

> e.g. DictionaryEntry, DictionaryEntryPresenter, DictionaryEntryCreation,<br>

> etc. then it makes it easier to navigate and fits in well with the concept<br>

> of connaissance.<br>

><br>

> It does lend well to namespacing, which then leads nicely into separating<br>

> into engines. And in one case, for an unused area of functionality it was a<br>

> surprising case of<br>

> rm -rf dictionary_entry specs/dictionary_entry<br>

><br>

> Run the specs and everything still works. Feature removed! (Then just<br>

> quietly remove the views and controllers/routes afterwards).<br>

><br>

> Didn't have time to look into getting that aspect smoothly done. But I would<br>

> probably better spend that time looking at trailblazer, which seems to have<br>

> a lot of great concepts in it.<br>

><br>

> Along these lines, I quite enjoy the concept of keeping the spec close to<br>

> the implementation as golang does. I've only gone as far as domain concept<br>

> based folders in the spec folder as mentioned. I'd be interested to hear if<br>

> anyone has had success with a directory listing that looks like this:<br>

><br>

> dictionary_entry.rb<br>

> dictionary_entry_spec.rb<br>

><br>

><br>

> The only fiddly issue apart from the views/controllers folders was with AR<br>

> and namespacing based on the domain concept. Which would traditionally be<br>

> the ActiveRecord model name.<br>

> E.g. rather than pollute a DictionaryEntry AR model with tons of classes, I<br>

> ended up namespacing all my AR models as Db::DictionaryEntry etc.<br>

> Which when you have lots of objects in an app serves a dual purpose of<br>

> hinting which one is the thing that writes to the db. Probably a<br>

> double-edged sword, hungarian notation anybody?<br>

><br>

> But equally, on a small app, with a few presenters, a few controllers and<br>

> non-obvious groupings then it is overkill. It doesn't really cost much more<br>

> to gradually introduce this kind of structure as appropriate.<br>

><br>

> On Wed, Sep 9, 2015 at 5:59 PM <<a>jc@panagile.com</a>> wrote:<br>

>><br>

>> Hi Enrico,<br>

>><br>

>> Thanks for sharing this. It’s an approach that I agree with in general -<br>

>> I’d much rather classes were grouped by domain than by pattern. I have got a<br>

>> couple of questions though:<br>

>><br>

>> 1) Why is it ok to end up with a directories for Controllers, Views and<br>

>> Helpers?<br>

>><br>

>> 2) Sometimes you are creating classes that fulfil specific roles within<br>

>> the framework; e.g, Presenters. How do identify their function when they<br>

>> aren’t grouped in a directory?<br>

>><br>

>> (Or maybe my assumtion at the start of the second question is wrong, in<br>

>> which case I’d like to hear why.)<br>

>><br>

>> Thanks,<br>

>> John<br>

>><br>

>><br>

>><br>

>> On Tue, Sep 8, 2015 at 5:43 PM, Enrico Teotti <<a>enrico.teotti@gmail.com</a>><br>

>> wrote:<br>

>>><br>

>>> Hi,<br>

>>><br>

>>> I wrote a blog post on (Rails) application directories named as<br>

>>> architectural patterns and suggesting a more intention revealing<br>

>>> alternative:<br>

>>><br>

>>><br>

>>> <a href="http://teotti.com/application-directories-named-as-architectural-patterns-antipattern/" target="_blank">http://teotti.com/application-directories-named-as-architectural-patterns-antipattern/</a><br>

>>><br>

>>> Ciao,<br>

>>><br>

>>> Enrico<br>

>>><br>

>>> --<br>

>>> [skype] enrico.teotti<br>

>>> [web] <a href="http://teotti.com" target="_blank">http://teotti.com</a><br>

>>> [twitter] agenteo<br>

>>> _______________________________________________<br>

>>> Chat mailing list<br>

>>> <a>Chat@lists.lrug.org</a><br>

>>> Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>

>>> Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>

>>> List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>

>><br>

>><br>

>> _______________________________________________<br>

>> Chat mailing list<br>

>> <a>Chat@lists.lrug.org</a><br>

>> Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>

>> Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>

>> List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>

><br>

><br>

> _______________________________________________<br>

> Chat mailing list<br>

> <a>Chat@lists.lrug.org</a><br>

> Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>

> Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>

> List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>

><br>

<br>

<br>

<br>

--<br>

[skype] enrico.teotti<br>

[web] <a href="http://teotti.com" target="_blank">http://teotti.com</a><br>

[twitter] agenteo<br>

</div><br><br>-- <br>[skype] enrico.teotti<br>[web] <a href="http://teotti.com" target="_blank">http://teotti.com</a><br>[twitter] agenteo<br>

</div></div><br>_______________________________________________<br>

Chat mailing list<br>

<a>Chat@lists.lrug.org</a><br>

Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>

Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>

List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>

<br></blockquote></div><br></div>

</blockquote></div></div>

</div>

</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Chat mailing list</span><br><span><a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a></span><br><span>Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org">http://lists.lrug.org/pipermail/chat-lrug.org</a></span><br><span>Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org">http://lists.lrug.org/options.cgi/chat-lrug.org</a></span><br><span>List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a></span><br></div></blockquote></body></html>