Models package - how to keep your models organized?

<p>How do you all keep your models organized? I recently created a db-to-code schema/model generator and am saving all in the same &#34;model&#34; package. The problem I encountered is from generated table-column pairs, ex:</p> <pre><code>table -&gt; account column -&gt; id // AccountID column -&gt; typeId // **AccountTypeID** table -&gt; account_type column -&gt; id // **AccountTypeID** </code></pre> <p>The issue is that I get generated column names AccountTypeID for both tables.</p> <p>There are definitely going to happen other cases of generated columns having the same name, so I think I&#39;d have to end up giving each model a separate package.</p> <hr/>**评论：**<br/><br/>TiberiusAbadon: <pre><p>I&#39;m seen a similar (maybe not) issue and solution in sqlx. </p> <p><a href="http://jmoiron.github.io/sqlx/#advancedScanning" rel="nofollow">http://jmoiron.github.io/sqlx/#advancedScanning</a></p> <p>Nothing wrong with asking the user to resolve possible ambiguities. With struct tags maybe?</p></pre>drink_with_me_to_day: <pre><p>I am generating &#34;static&#34; models, no tags or dependency on reflect. </p></pre>driusan: <pre><p>Without seeing the code that you&#39;re generating, I don&#39;t see where the conceptual problem is. It sounds like you&#39;re making everything too flat. If I were writing something to represent those tables from scratch instead of generating it, I&#39;d expect it to be something like:</p> <pre><code>type AccountTableRow struct { Id int TypeId *AccountTypeTableRow } type AccountTypeTableRow struct { Id int } </code></pre> <p>There&#39;s no conflict there..</p></pre>Akkifokkusu: <pre><p>Instead of having a <code>models</code> package, have you thought about organizing your code in a different way? <a href="https://medium.com/@msandin/strategies-for-organizing-code-2c9d690b6f33#.p75r9thd1" rel="nofollow">This article</a> is a pretty good overview, and to me having a <code>models</code> package is code smell that falls under the &#34;By Kind&#34; category.</p> <p>I&#39;d have packages for <code>account</code> and <code>accounttype</code>that encapsulate the logic related to dealing with each one.</p></pre>drink_with_me_to_day: <pre><p>That was a good read. Having separate packages for each model might work.</p></pre>