edit image and text in D.S. Internal Flow.

master
Craig Oates 5 years ago
parent
commit
61f524f30f
  1. 2
      DeathSockets-Internal-Flow.md
  2. BIN
      attachments/deathsocket-internal-flow.png

2
DeathSockets-Internal-Flow.md

@ -2,7 +2,7 @@ Although the system has a restricted input-output (I/O) flow from the outside, t
![deathsocket internal flow](attachments/deathsocket-internal-flow.png)
How this works is `GridPainter` receives input, usually a record type from `Domain`. From there, `GridPainter` utilises the various functions from the other files to complete the task it received. Because everything runs through`GridPainter`, it doubles up as the libraries co-ordinator. There is (for lack of a better word) no cross-pollination of function calls between the other files.
How this works is `GridPainter` receives input, usually a record type provided by `Domain`. From there, `GridPainter` will validate the input by making calls to `validation`. If the input is valid, `GridPainter` calls into `ImageServices` which then makes the various calls into `ColourServices` and `ImagePrep`. When the task is complete, `ImagesServices` returns the output to `GridPainter` which then returns it to your/the bigger system.
If you decide to add new features to the library, please try to keep to this flow/structure.

BIN
attachments/deathsocket-internal-flow.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 41 KiB

After

Width:  |  Height:  |  Size: 63 KiB

Loading…
Cancel
Save