Introduces a set of DataStructure/Models and functions which operate on them. Instead of modifying the core you should be able to compose and build upon the foundation provided by nectar.
Separation of read and writes.
Separates all reads from writes. Models now have no logic pertaining to db access or queries instead they only define the changesets, validations and stateless business logic.
All DB Access (Which is the only source of side effects) happens through three different categories of Modules:
Query
Command
Workflow
Query as the name suggest are used to load and verify facts about the model from the database. There are no writes here. Neither, do we read the Model Struct in the query module.
Commands are solely used to write to and modify a single model and its association. Only one CRUD operation per command method is allowed.
Workflows will be the primary unit of abstraction and extension for nectar. They are thin wrappers around Ecto's Multi, within which you can combine multiple Commands, Queries and other workflows to build bigger workflows. The general structure of workflow is
defmodule WorkflowModule do
def run(repo, params) do
repo.transaction(steps(params))
end
def steps(params) do
# return steps to execute wrapped in Ecto.Multi
end
end
The steps of one workflow can be built of multiple smaller workflows. For example: cancel line items is composed of restocking and recalculation workflows.
Repository as a parameter
We never access the Repository directly in the Command, Query or Workflows ,instead they are passed the repository as their first param. This paves way for future use cases where we can use nectar as part of other phoenix applications with the host application's Repo.
Future of Nectar Extensions
With all this we still want Nectar's Core Models to be extensible. Providing a stable baseline for which Core Functionality is written. Other Extensions may Add to the Core Models and provide their own set of workflows, commands and queries which the end User can then utilise and compose into their store built on NectarCommerce.
Introduces a set of DataStructure/Models and functions which operate on them. Instead of modifying the core you should be able to compose and build upon the foundation provided by nectar.
Separation of read and writes.
Separates all reads from writes. Models now have no logic pertaining to db access or queries instead they only define the
changesets, validations and stateless business logic.All DB Access (Which is the only source of side effects) happens through three different categories of Modules:
Query as the name suggest are used to load and verify facts about the model from the database. There are no writes here. Neither, do we read the Model Struct in the query module.
Commands are solely used to write to and modify a single model and its association. Only one CRUD operation per command method is allowed.
Workflows will be the primary unit of abstraction and extension for nectar. They are thin wrappers around Ecto's Multi, within which you can combine multiple Commands, Queries and other workflows to build bigger workflows. The general structure of workflow is
The steps of one workflow can be built of multiple smaller workflows. For example: cancel line items is composed of restocking and recalculation workflows.
Repository as a parameter
We never access the Repository directly in the Command, Query or Workflows ,instead they are passed the repository as their first param. This paves way for future use cases where we can use nectar as part of other phoenix applications with the host application's Repo.
Future of Nectar Extensions
With all this we still want Nectar's Core Models to be extensible. Providing a stable baseline for which Core Functionality is written. Other Extensions may Add to the Core Models and provide their own set of workflows, commands and queries which the end User can then utilise and compose into their store built on NectarCommerce.