4 ms·

simple read. good points. this is very useful in event sourcing or in general for sensitive data where mutability might become an issue(ie. financial transactio

by 02020202 6y ago

simple read. good points. this is very useful in event sourcing or in general for sensitive data where mutability might become an issue(ie. financial transactions). also i think this maps to value object perfectly. i have implemented ES into few projects and am now writing a ES library, since I think it can be done much simpler than my previous implementations that felt too verbose, and I will take some pointers from this into account.

viebel 6y ago
Could you share an example of how to apply the principles of DO in the context of event sourcing?
- dathinab 6y ago
  A entity component system (ECS) as used by many games would probably fall under DO. Through I would argue that #5 isn't part of DO. Especially given that e.g. `{ "a" : "b" }` is not necessary a literal but potentially an expression (depending on arbitrary language definition aspects). On the other hand e.g. `vec![ "a" ]` in rust is definitionally not an literal but wrt. to the idea behind principle #5 as good as `[ "a" ]` in JavaScript. EDIT: Lastly sometimes contexts using something like a builder pattern can be the better way to "not verbose creation" and "data is exploreable in any context".
  - viebel 6y ago
    What do you mean when you write that `{ "a" : "b" }` is not necessary a literal but potentially an expression?
    - dathinab 6y ago
      Depending on how a language defines their syntax. Often times literals are only things like `"string"`, `0` and so one. But thinks like `[ 1,2]` would be a array expression where each "entry" is syntax wise an expression (and any literal is an expression itself). I don't know if JavaScript specifically does define object literals or object expressions, in the end it depends on what you define a literal as. Lastly depending on the language something like `[ 1,2]` might literally de-sugar to something like following pseudo code `var tmp = Array.new(capacity=2); tmp.push(1); temp.push(2)`. So a better way would be that a formulation like "data should be creatable without explicitly doing any function calls, variable assignments or similar. Creation must not depend on implicitly captured data".
      - viebel 6y ago
        I totally agree with "data should be creatable without explicitly doing any function calls, variable assignments or similar." Could you explain what you mean by "Creation must not depend on implicitly captured data"?
        dathinab 6y ago
        Lets say you have a language which has some form of macro system or similar to make creation of new thinks which look like literal-like expression easier. E.g. instead of `a = [1,2]` you have `a = vec![1,2]` which de-sugars to `a = Vec::with_capacity(2); a.push(1); a.push(2);`. Now custom data structures can define their own macros like that, e.g. `skip_list![1,2]`. Which would be all fine. But what if now `bad_skip_list![1,2]` accesses a thread local variable (or other implicit provided data) and adds that, too? Now `bad_skip_list![1,2]` might be not equal to `bad_skip_list![1,2]` defined somewhere else. Which is against the ideas behind the rule #5. You should be able to copy-past the literal-like creation of data to any place (e.g. a unit-test) and get the same result. EDIT: If I remember correctly you could override parts of `Array.prototype` and array construction in JavaScript to brake the #5 for JavaScript for thinks like `[1,2,3]` but I'm not to sure about that anymore.
  - petermcneeley 6y ago
    I think DOD of games is only tangentially related to this post. https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design
    - dathinab 6y ago
      The "DOD of games" is just a "special case" of more generic Data Orientated design/programming. E.g. ECS is a direct consequence of seperating data from code. Furthermore for it to work well you normally also want #2, #3 and #4. Sure you can build a ECS without #2,#3 and #4 but it makes it more complex. Lastly in a ECS you split up components into many parts each having their own data and you normally want the idea behind #5 to apply to each of the parts. EDIT: Well ok, weather #2 makes any sense at all depends on the language you use. And using a language where #2 makes no sense can be a as reasonable choice. I only would apply #2 IF it makes sense for you language of choice.

viebel 6y ago

Could you share an example of how to apply the principles of DO in the context of event sourcing?

dathinab 6y ago
A entity component system (ECS) as used by many games would probably fall under DO. Through I would argue that #5 isn't part of DO. Especially given that e.g. `{ "a" : "b" }` is not necessary a literal but potentially an expression (depending on arbitrary language definition aspects). On the other hand e.g. `vec![ "a" ]` in rust is definitionally not an literal but wrt. to the idea behind principle #5 as good as `[ "a" ]` in JavaScript. EDIT: Lastly sometimes contexts using something like a builder pattern can be the better way to "not verbose creation" and "data is exploreable in any context".
- viebel 6y ago
  What do you mean when you write that `{ "a" : "b" }` is not necessary a literal but potentially an expression?
  - dathinab 6y ago
    Depending on how a language defines their syntax. Often times literals are only things like `"string"`, `0` and so one. But thinks like `[ 1,2]` would be a array expression where each "entry" is syntax wise an expression (and any literal is an expression itself). I don't know if JavaScript specifically does define object literals or object expressions, in the end it depends on what you define a literal as. Lastly depending on the language something like `[ 1,2]` might literally de-sugar to something like following pseudo code `var tmp = Array.new(capacity=2); tmp.push(1); temp.push(2)`. So a better way would be that a formulation like "data should be creatable without explicitly doing any function calls, variable assignments or similar. Creation must not depend on implicitly captured data".
    - viebel 6y ago
      I totally agree with "data should be creatable without explicitly doing any function calls, variable assignments or similar." Could you explain what you mean by "Creation must not depend on implicitly captured data"?
      - dathinab 6y ago
        Lets say you have a language which has some form of macro system or similar to make creation of new thinks which look like literal-like expression easier. E.g. instead of `a = [1,2]` you have `a = vec![1,2]` which de-sugars to `a = Vec::with_capacity(2); a.push(1); a.push(2);`. Now custom data structures can define their own macros like that, e.g. `skip_list![1,2]`. Which would be all fine. But what if now `bad_skip_list![1,2]` accesses a thread local variable (or other implicit provided data) and adds that, too? Now `bad_skip_list![1,2]` might be not equal to `bad_skip_list![1,2]` defined somewhere else. Which is against the ideas behind the rule #5. You should be able to copy-past the literal-like creation of data to any place (e.g. a unit-test) and get the same result. EDIT: If I remember correctly you could override parts of `Array.prototype` and array construction in JavaScript to brake the #5 for JavaScript for thinks like `[1,2,3]` but I'm not to sure about that anymore.
- petermcneeley 6y ago
  I think DOD of games is only tangentially related to this post. https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design
  - dathinab 6y ago
    The "DOD of games" is just a "special case" of more generic Data Orientated design/programming. E.g. ECS is a direct consequence of seperating data from code. Furthermore for it to work well you normally also want #2, #3 and #4. Sure you can build a ECS without #2,#3 and #4 but it makes it more complex. Lastly in a ECS you split up components into many parts each having their own data and you normally want the idea behind #5 to apply to each of the parts. EDIT: Well ok, weather #2 makes any sense at all depends on the language you use. And using a language where #2 makes no sense can be a as reasonable choice. I only would apply #2 IF it makes sense for you language of choice.