Open barryosull opened 8 years ago
Let's begin by extracting the validation aspect
Let's clarify some concepts in the validator aspect of the language, we have the following
ValueObjects: Named, can contain a single checker, or a composite tree of value objects Checker: Compares a value to one or many validators Validator: Passes a value through a validation stage, ensures it meets criteria Entity: Named composite tree of valueobjects, must have an id field
Command/Event: Entities with more complex composite attributes, these composite attributes are never used inside the composition stage (except maybe id) only outside of it, this is causing unneeded complexity. Need to think more about this.
Next step is to move the Update SQL interpreter code into the modification module, as that's where it belongs.
The Update SQL interpreter does belong to the Modification concept, but the projection side hasn't been fleshed out enough to move it properly. There are a couple of concepts at play here moving it now may make future changes more difficult.
Eg. The query and modification systems will be called in different places, under different contexts. They may need to be extracted into their own infrastructure implementation for projections, leaving the original code in place. Tricky.
Solution: Split the interpreter into multiple, mini interpreters SuccessCriteria: Code is restructued into new, inter connected modules. Tests continue to pass.
The first step is figuring out where the lines should be drawn. Thankfully we've already done part of this work in with issue #161.
Each of the below structures have their own syntax that's self contained, so realistically these could be split into independent parsers and interpreters that are then glued together via interfaces.
Validation
Other systems will make calls to this system
Querying
Modification Modifications to the root entity, replacing values/entities in the tree
Composition Mostly the command handler, it composes components together to perform operations