<div dir="ltr">The plan is to move the remote work item code out of the 'models' package into a 'remoteworkitem' package as we talked about a few days ago. The mapper is moved, but the 'tracker' is still in PR and not updated yet.<div><br></div><div>Part of the reason why it's being moved to the 'remoteworkitem' package is to unclutter the 'models' package (should be removed in general) and in 'preparation' for it to be it's own service in the future.</div><div><br></div><div>-aslak-</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 31, 2016 at 10:58 AM, Thomas Mäder <span dir="ltr"><<a href="mailto:tmader@redhat.com" target="_blank">tmader@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Folks,<br>
<br>
as our code base grows, I'm asking myself where the boundaries of the "alm" service should lie. If we are building a monolith, we need a way to structure our namespace or we'll end up with monster packages. The case at hand is the remote issue replication service (see <a href="https://github.com/almighty/almighty-core/issues/130" rel="noreferrer" target="_blank">https://github.com/almighty/al<wbr>mighty-core/issues/130</a> - 135). The service could function entirely as a microservice "USING" the work item storage service as a client. Instead, it lives in the same package ("models", etc) and extends the API of the current service.<br>
<br>
Is a microservice architecture what we strive for? If not, how can we structure our package namespace to keep separate concerns separate?<br>
<br>
Opinions?<br>
<br>
/Thomas<br>
<br>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
</blockquote></div><br></div>