Separate project source files in persistence and domain layers

[yeraydavidrodriguez]

The project as it is now is organized in a raw list of files. However, there is at list two clear levels of abstraction:

• The PERSISTENCE (or storage) layer is the group of entities that deals with the repository (or, in general, database structure) operations. Basically, all files that deals with GIT are to be here.
• The DOMAIN is te group of entities that represents the queue objects, at a higher (independent from storage and particular technology-based descriptions) level.

It would be easy and convenient to make explicit those layers by creating two folders inside the root source folder and sorting the files between them.

[josecelano]

I've created this diagram with "belongs-to" relationships.

I do not think it makes sense to create the two layers because:

• We still have very few classes.
• Our domain classes are coupled to the persistence layer. Some commands return the Job class and other commands return CommitInfo which contains persistence details. I suppose we consider git commits part of our domain, it's not only storage for queue jobs. In fact, the commit is more important than the job state. We do not even store the job state in the Job class.

On the other hand, in the version 2.0 we might not use event sourcing to store job state.

@yeraydavidrodriguez @da2ce7 what do you think? Maybe before implementing this change we should review the queue API and decide if we want to decouple the persistence.

Maybe we could return a new object containing the Job and the CommitInfo although I would do it after refactoring the Queue. I think the code would be simpler if we introduce an array of Job in memory with the current state of the jobs, instead of dealing with messages. The array of messages would be only a way to store jobs.

[yeraydavidrodriguez]

You are right that creating the two layers is not as easy as moving files to folders, and probably is not possible in the current version without a big refactor that may not be worth, as the new version is going to be developed soon.

However, it looks somehow weird to me considering git commits part of the domain. It's true that "it's not only storage for queue jobs" and "the commit is more important than the job state", but maybe that's is a symptom of some design flaw.

I do not think that this implementation should be refactored, but I think we should answer now those questions for the queue 2.0:

• It's clear that we want to store domain information on the actual GIT commits, but, do we want to keep this information on the classes that represent those commit, or shall we use those classes as a converter tool to a higher-level representation?

• Do we want to couple the representation classes to GIT? Although GIT-based storage is part of the core concept, maybe it's not actually needed to actually coupling it.

[josecelano]

I think one important goal for git-queue is traceability. Having code commits linked to queue commits could give you a good snapshot of what happened at a given time. If we remove those links we would only have timestamps to link the code state and job states. Maybe we have to keep the link but not as a direct link. Code commits could contain job ids (in the commit body footer) and internally (in the queue branch) you can get the job processing history. The same way, you keep issues and code separated in a normal development process.

It seems that if we choose the "transient job queue" model (what was initially called the best-effort model) for the queue, when the job process started or finished is not as important as when the result was merged.

I'm going to close this issue for now. For this version, it does not make sense the change since it was designed to be coupled.