These are chat archives for jdubray/sam

25th
Oct 2017
Jean-Jacques Dubray
@jdubray
Oct 25 2017 00:14
@jannesiera maybe I didn't convey precisely what I meant, you will of course always use a precise definition that will vary in context, you never use all aspects of that definition at any given moment. For instance Optics, General Relativity and Quantum Mechanics use all a very different definition of light, matter, and forces or even energy. As such I view these concepts more as "categories" than "things". As physical beings, humans always need to reify every-thing to a thing, but in practice they are categories of building blocks, a framework to reason about a particular phenomenon.
The same conceptual framework (STAR) can be used to describe business strategy, problem statements, solution specifications, programming models, and correctness. For instance: http://xgenio.com/bolt-introduction.pdf
In each case, the definition will vary slightly but as a category it will not.
In each context you need to come up with a (more) precise definition, hopefully compatible each time.
Jean-Jacques Dubray
@jdubray
Oct 25 2017 00:38
@jannesiera take this paper for instance (just random) https://blog.codecentric.de/en/2017/02/cqrs-event-sourcing-lagom/
wouldn't you need something like STAR (as categories) to make sense of it and explain how different or similar it is to other approaches?
Paolo Furini
@pfurini
Oct 25 2017 07:14
@jdubray haven't read it, but then if lagom approach is wrong, how would you make it STAR compliant?
It's practical advice and solutions that helps everything going mainstream.. without it, someone could say: well maybe lagom is fundamentally wrong, but I can use it today and it works better than something that doesn't exist ..
We all have to pay our bills at the end, and theory never made it for me .. 😬
Jean-Jacques Dubray
@jdubray
Oct 25 2017 07:19
I would not claim it's wrong, but STAR would help you categorize concepts to see if there are missing concepts or if the existing concepts are "wired" improperly.
STAR is very practical, it actually will save lots of time to use its categorization.
From STAR's perspective, both Queries and Commands are "actions" which put the system in a particular "State", we understand why they are different kinds of actions.
I have issues with the "event" concept and event sourcing as we discussed before because it assumes that either:
  • business logic does not change at all
  • if it changes, events can be "replayed"
Jean-Jacques Dubray
@jdubray
Oct 25 2017 07:24
It would also depend how "updates" from events to states are defined.
Immediately you start questioning the structure of "events" (which are not "events" since the definition of an event is "the occurence of a state")
It seems a bit convoluted
At least something to investigate and clarify
I make the claim that every computing paradigm maps to STAR and there is value in doing so.
Paolo Furini
@pfurini
Oct 25 2017 07:30
To be honest, I have the same feelings about events, I have never seen a precise definition that took into account replicability and rollback
Jean-Jacques Dubray
@jdubray
Oct 25 2017 07:30
Another obvious missing concept is "relation", how does CQRS deal with "relations"? it doesn't, it's up to you do deal with them, that's when the consistency comes into play.
All I am trying to say is that we must find a common level in such discussion such that we can compare and constrats software engineering paradigms, it does not mean they are 100% wrong, but at least, you can quickly understand the limitations before it's too late. For instance if your data model is highly relational, you know instinctively that early on you have to focus your attention on how you will layer that concept on top of CQRS. It's not something you can do afterwards.
Paolo Furini
@pfurini
Oct 25 2017 07:32
But then why not take one of this approaches/framework and try to reify it and reason about its fallacies using STAR as a guideline? I mean, write some article that put in context these concepts
Jean-Jacques Dubray
@jdubray
Oct 25 2017 07:33
Fallacy is perthaps too strong, I am sure a lot of people feel they have found a good approach, but usually it's impossible to evaluate all the contexts in which it can be applied. There is also no "common level of reference" from which we can offer some comparison, it becomes my approach vs yours, in the end we are all wrong in some context.
I am just saying there is value in finding such a level of discussion, I suggest it is STAR, I may be wrong, it's ok, happy to use something better, but it cannot be much more complex (say like UML), it has to be more fundamental/elemental.
Yesterday someone was bitching about Single State Trees in React: https://twitter.com/acemarke/status/922914557361659904
The recommendation is a bit fluffy akin to "preferences", IMHO, there should be a level where this can discussed more straightfully.
Jean-Jacques Dubray
@jdubray
Oct 25 2017 07:42
If we go back to CQRS and the proposed architecture you also see that the relationship from Command/Event to State is not well defined, what is an "update" which part of the software computes it? the event? if not, is the event exactly specifying the updates that need to happen? All these questions need to be asked. Otherwise, can you even start writing code? I am not trying to say CQRS is good or bad, I am just trying to illustrate that for decades our industry has adopted countless programming paradigms, from CORBA to EJB to CQRS and anything in between and I have absolutely never seen this kind of discussion happening. Wherever there is void, hype and Cargo Cults move in.
It's really the same in physics, you observe new phenomena, to explain it you look at where it the light, the matter, energy and forces, then you identify a relationship between them that makes sense and can explain a particular observation. I am questioning why this is not possible in Software Engineering.
Paolo Furini
@pfurini
Oct 25 2017 07:48
I have the same feeling after reading the lagom introduction.. no mention on how to deal with side effects, or consistency when N services are involved in executing a command, that spread X events and that events have side effects. How can I track those side effects, and how can I recover from failure ?
Jean-Jacques Dubray
@jdubray
Oct 25 2017 07:51
Yes, again, I am not trying to hit on that article, but right there STAR gives a structure either for the author or for the reader to reach a common understanding much faster. Perhaps the author knows the answers to these questions but he chose to structure his article from a different point of view.
I did have a talk with a world famous CQRS/DDD expert and our discussion stopped when we started to talk about relationships. He basically told me that it would take on average 7-10 years for a company to slice and dice their information model to the point where this architecture will work.
Paolo Furini
@pfurini
Oct 25 2017 07:53
Yes that's in general a problem with the micro services architecture
If you have a highly decentralized information model from the start, you can reason about creating independent and collaborating services, but most of the time I have to deal with large related data stores and in the end even if I reason about collaborating services, they end up to be tied with a central data store
Jean-Jacques Dubray
@jdubray
Oct 25 2017 07:58
:+1: