[almighty] Potential cyclic import issue in core.

[Pranav Gore]

Thank you Thomas for time and inputs.

I am tracking the progress here
<https://github.com/almighty/almighty-core/issues/374>.

First step taken towards breaking the packages into multiple in this PR
<https://github.com/aslakknutsen/almighty-core/pull/7>.

On Wed, Oct 12, 2016 at 1:42 PM, Thomas Mäder <tmader at redhat.com> wrote:

> Hi Pranav,
>
> On 10/12/2016 04:36 AM, Pranav Gore wrote:
>
>  When we say a system-layer., is it a bunch of related packages ? Or a
> layer is a package.
>
> No, a layer is more abstract: for example the API layer would take care of
> handling json requests via htttp, the database layer stores things in the
> db. The characteristics of a layered approach is that you can only call
> things from layers "beneath" you, not above you. The package structure must
> follow this layering to some extent in order for build system to know what
> to compile first.
> Structuring a system in layers is a design choice we are free to make or
> not. Layering imposes certain restrictions on the code you write. The
> reason you would want those restrictions is to separate the system into
> parts with controlled interfaces. This reduces coupling between the layers.
> Code with uncontrolled coupling everywhere is what is generally referred to
> as "spaghettig code". It gets hard to change and to understand the possible
> consequences.
>
> @Thomas, is this (#110)
> <https://github.com/almighty/almighty-core/issues/110> existing
> architecture issue for the same ? If yes, I will update the same.
>
> Issue #110 talks about something related, but slightly different: the
> structs we use for storage with gorm are adapted to the purpose of storage.
> The structs generated from our goa design are adapted for use in the API.
> The structures in both layers are not what we would come up if we tried to
> design our data model free of constraints. #110 raises the issue whether we
> need that "ideal" layer between the API and the db.
>
> /Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161018/835a8634/attachment.htm>