Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

"System Layering" in core. #374

Closed
pranavgore09 opened this issue Oct 18, 2016 · 2 comments
Closed

"System Layering" in core. #374

pranavgore09 opened this issue Oct 18, 2016 · 2 comments

Comments

@pranavgore09
Copy link
Contributor

Problem Statement : Mailing-List Message

Discussion to be done with following inputs.

Kinds of code we have (Ref):

  • Repository interfaces : They define an interface for persistence in terms of application level objects. The repository interfaces are not supposed to be gorm specific. The idea is to be able to replace the implementation in tests and to avoid coupling consumers to gorm.
  • Repository implementations : They implement the repository implementations in a gorm-specific way. They are free to convert app layer objects to a different form. For example, we store work items as JSON in the db, which only has very few data types (number, string, bool, etc.). The repository implementations convert and validate the work item fields according to a given work item type.
  • Gorm support stuff : Stuff like models.Lifecycle, GormTransactionSupport, etc. This is shared infrastructure for implementing repositories.

What layering means? (Ref)
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.

So, should we define layers in our system ?

@pranavgore09
Copy link
Contributor Author

pranavgore09 commented Oct 18, 2016

First step taken towards breaking the packages into multiple in #386

@pranavgore09
Copy link
Contributor Author

In better shape now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants