These are chat archives for jdubray/sam

30th
Jun 2017
Jean-Jacques Dubray
@jdubray
Jun 30 2017 14:37

I think this is a great testing framework for SAM (actions, acceptors, state function, next state or view components). It's kind of manual, nothing really magic.

https://www.sitepoint.com/bdd-javascript-cucumber-gherkin/

Rob Siera
@robsiera
Jun 30 2017 15:37
in the opening sentence of SAM.js.org you say that SAM "simplifies Front-End architectures". What would be its effect/role/benefit on the server? As STAR# is clearly a server component.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 15:48
@robsiera you can use SAM strictly on the front-end with an API back-end or you can actually use SAM in a full-stack architecture:
http://www.ebpml.org/blog15/2016/08/services-apis-and-microservices-part-2/
The STAR library is another way to implement the SAM pattern but in a more "state-machine" way which you may not always want to do. In a Front-End architecture you'd end up having to manage too many states and it would become cumbersome.
Rob Siera
@robsiera
Jun 30 2017 15:51
So STATE is strictly a Front-end concept? (based a image on the that page)
Jean-Jacques Dubray
@jdubray
Jun 30 2017 15:51
That's one thing I like a lot about SAM is that there is no discontinuity between a classical state machine semantics and standard coding practices. You can use as many "states" at it makes sense or as few as necessary.
Not quite
SAM makes a disctinction between State and View
you compute the View from the State but there could be systems with no view
I never found any instance yet where the semantics of the pattern break
(front-end, back-end...) it's truly a Software Engineering pattern
From the Star library you can compute a view from the State
one way to look at it is the State function outputs a State Representation of the model
that State Representation can be used to compute the view. Because it's at the end of a step, the State Representation is consistent until the next step is executed.
In Angular2 for instance I use publish/subscribe to pass the State Representation to the View which then renders
The A/M/S buckets are very general to organize your code. Any event handler can be structured that way.
... and should be structured.
For state machine semantics SAM works with if-then-else or it works will well defined States like in the STAR library
Jean-Jacques Dubray
@jdubray
Jun 30 2017 15:57
For me that has been the wholly grail because classical State Machine semantics don't work and pure imperative (or declarative) programming doesn't work either (at least from my perspective)
SAM provides the right balance between them in a unified programming model
SAM is wiring and architecture independent, you can choose where you deploy every element of the pattern, including parent/child instances
Since it is unidirectional, it's very easy to wire
Rob Siera
@robsiera
Jun 30 2017 16:03
Thx. Looking for a way to get C# more in 'the story'. I had hoped STAR port would give me that. Apparently it does that, partially.
Rob Siera
@robsiera
Jun 30 2017 16:13
I really have the impression that SAM fits nicely with DDD. And I mean the base of DDD: the ubiquitous language, not the coding samples written +10years ago.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 16:32
I am not a big fan of DDD, but it is for sure not incompatible. Data is relational, there is nothing we can do about it. We can be smart about bounded contexts and making sure we do not traverse too many relations across service boundaries. I feel that SAM is the missing link in Microservice architectures because it provides a natural way to achieve consistency. The STAR library is very good at that.
The way to use the STAR library in a server based front-end architecture is to:
1/ wire requests to actions (via a dispatcher)
2/ then A->M->S gets executed
3/ you wire the response to the request to the State's function
4/ Once the response is returned to the browser the state representation is passed to the view components for rendering
You will need to manage the session to rehydrate the user/session's model
If you need some precisions let me know
STAR would be very good for a microservices based backend (below the Model).
If you have just one backend, it's less useful.
But still works of course
Rob Siera
@robsiera
Jun 30 2017 16:46
"I am not a big fan of DDD" I noticed that. That I why I suggested you to guys behind DDD Europe. Great conference , especially because DDD gets challenged there. So, if you ever get an invite, you can blame me ;-)
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:01
it's ok, I am not against it, I just feel it's a Cargo Cult, doesn't hurt anyone but doesn't get much done compared to common sense.
Making sense of the rapidly changing React best practice... uh??
https://medium.freecodecamp.org/understanding-higher-order-components-6ce359d761b
I had a discussion with someone heavily vested in DDD (he runs a 50 person business on it) and well the answer was not pretty when I asked, so tell me what is the end state of a well designed DDD system? He told me it would take on average 10 years for a company to reach it. We also talked about consistency in the context of event / orchestration, and well, again the answer was not pretty. Not much better compared to raw common sense.
Rob Siera
@robsiera
Jun 30 2017 17:09
sure, DDD doesn't solve the problem that SAM solves, although some might have hoped it would.
Any good DDD conference will teach you that DDD is not about the code. Which is a pity, as the industry still has some issues there.
SAM tackles those, I think, I hope, I sense
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:11
yes, my point exactly, I always looked at it (and continue to look at it) with the hope that there will be some meat behind it, but I get disappointed each time.
Rob Siera
@robsiera
Jun 30 2017 17:11
well, we needed common sense. DDD give you that.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:11
Yes, "State" has been the common thread of my career, from Business Process to B2B, to SOA/APIs, to Full-Stack Architectures.
Rob Siera
@robsiera
Jun 30 2017 17:12
For years I was on a quest to the perfect all-inclusive-model. DDD convinced me to stop.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:12
SAM provides a unified way to solve all these problems. It does not solves BPM by bringing a "business process engine" in a Full-Stack Architecture, but it makes it very for a FSA to automate business processes
yes, agreed
I stopped many times
Unfortunately without a robust way to deal with consistency, DDD has zero value
The real mistake of the industry has been to ignore state, kick down the can, instead of embracing it.
Rob Siera
@robsiera
Jun 30 2017 17:15
sure, zero value, on the coding level, but on talking about models, action, contexts, many in the industry still needs to get some common sense
that is what DDD is really about, not about code.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:16
Maybe I am too harsh when I say zero value, but I compare it to common sense.
Common sense has value too!
Rob Siera
@robsiera
Jun 30 2017 17:17
there is a lot common sense missing.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:18
So far, SAM was the structure I was looking for. I can apply common sense everywhere else without worrying how my code is structured.
Rob Siera
@robsiera
Jun 30 2017 17:18
and sure, its views might be dated, especially from your point of view. But, I'm telling you, DDD Europe conference was about looking for answers, not code samples.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:19
it's ok, if I get an invite I'd be happy to go if my health allows me too.
Rob Siera
@robsiera
Jun 30 2017 17:19
Indeed, that is what I really like about SAM.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:19
I never landed in a corner where I felt, ok, let's scrap everything.
Rob Siera
@robsiera
Jun 30 2017 17:20
would be difficult, if you ARE the corner
What do AS and BS mean in this image ?
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:22
Application Server and Business Service
APIs (activity oriented interface)
Service (Proper SOA service)
That's the kind of things I see missing in DDD
The bounded context is way way back
Rob Siera
@robsiera
Jun 30 2017 17:30
BC is just about splitting up the model, which, if i'm correct, is (sometimes?) 'persieved' as the State. Not sure if different concept is meant then SAM-State.
Its not more 'way back' then here
where model is on server side
BC is saying, "not àll your views have the same SUPER MODEL"
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:33
BC??
Rob Siera
@robsiera
Jun 30 2017 17:34
Bounded Context
DDD lingo :-)
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:37
Sorry, of course
well, the service layer has to because of consistency reasons
When you build an information system you have to think about these three layers (API/Service/SOR) independently
even if you code every in a single event handler
Normalization of the bounded context (the thing that takes 10 years to achieve) is not necessarily cheaper than consistency when you can achieve consistency easily.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:43
Before SAM consistency was extremely expensive (think BPEL). Coding consistency in Java or Javascript or C# was not an option.
Rob Siera
@robsiera
Jun 30 2017 17:43
idd, idd, and as such SAM should be embraced by DDD.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:45
yes, I am not quite sure why more people do not look at it. It's super simple, yet it changes everything, at least for me.
I no longer fight with State, I have a consistent and proven way to deal with it.
compared to ad hoc or clunky (BPEL) way
I was one of the original co-authors of SCA (Service Component Architecture) and what was done there (by IBM) was quite smart they defined a component model that allowed you to mix BPEL components with Java Components, but they did that because they had no other way to manage long running state, not because it was pretty.
But it was pretty much the first time that we acknowledge that long running state can't be dealt with Java/C# (back then).
SAM changes that
And, you could not implement BPEL with classical State Machines either, there was a huge mismatch across all these concepts.
BPEL had good semantics (not great) but a terrible architecture
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:52
All these concepts are interconnected, you cannot just think in terms of DDD and not have something like BPEL (or course not BPEL itself). The reason why DDD sounds incomplete is precisely because they could not pick BPEL, so they picked the next thing on the table, EDA.
Rob Siera
@robsiera
Jun 30 2017 17:52
"not quite sure why more people do not look at it" One can only learn something new by linking it to what one already knows. Notice how I'm trying to find overlap with DDD, because that is what I know. I'm don't want to prove that DDD is already doing what SAM does. On the contrary. I'm desperately looking for overlap to make the next leap. Because I can only work with what I know, and change that. That is why I want a simple C# demo. Maybe you blog starting point, but with c# backend. That would help those people look at it.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 17:52
Once you pick EDA you have to drive towards the normalization of your information system because it's very hard to achieve consistency in EDA
I don't feel they are conflicting, they should work together well
DDD and model should align well. It should actually help DDD adoption, because SAM removes the need for creating a lot of APIs bound to views
The actions/APIs in SAM are bound to activities not views
Jean-Jacques Dubray
@jdubray
Jun 30 2017 18:00
Have to head to a meeting
Jean-Jacques Dubray
@jdubray
Jun 30 2017 19:34
@robsiera if you are interested to write an article on DDD + SAM, I'd be happy to co-author it. Sounds like an interesting topic.
Marcus Feitoza
@mfeitoza
Jun 30 2017 19:41
In my short study I think SAM model align well with command and query + DDD ubiquitous language, is similar to Event Sourcing
Jean-Jacques Dubray
@jdubray
Jun 30 2017 19:43
I'd argue that SAM aligns well will lots of application architecture concepts (but I am biased :-)
Marcus Feitoza
@mfeitoza
Jun 30 2017 19:47
same.png
Jean-Jacques Dubray
@jdubray
Jun 30 2017 19:50
nice! :thumbsup:
Marcus Feitoza
@mfeitoza
Jun 30 2017 19:50
Any suggestions? Is my first digital draft from my concept for a logo to my framework:
Some hints:
  • Orange: Proposal/action
  • Three blue lines: acceptor/learn
  • Black and Gray lines: Reactive Loop/Mutation (from DNA)/ maybe can see lambda
Jean-Jacques Dubray
@jdubray
Jun 30 2017 19:51
that's a busy interpretation
I was seeing it as a bird
Marcus Feitoza
@mfeitoza
Jun 30 2017 19:58
Wow, I try but I can't see a bird. But my goal is to represent proposal/acceptor
I will try simplify.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 20:02
it's ok, it's nice!
Rob Siera
@robsiera
Jun 30 2017 20:14
thx @jdubray for the offer to co-author an article SAM/DDD. It is a good idea. I'll remember that. I'm not the right person, but I'll keep an eyes open for a better candidate.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 20:30
ok
Rob Siera
@robsiera
Jun 30 2017 20:36
another idea, to help people getting there head around the new concepts, is write an article like this: http://julienletrouit.com/?p=22. Transition from a traditional approach to the SAM approach. Of course if that 's an possibility all together.
are you sometimes in Europe?
Rob Siera
@robsiera
Jun 30 2017 21:10
Reading this article of you I think that the problem you are tackling, with your CIM and Type Variants, is the same as DDD/CQRS is tackling, with Bounded Contexts and ReadModels.
Jean-Jacques Dubray
@jdubray
Jun 30 2017 21:38
yes, I think it's related but I don't know if they are trying to do it at the same level. The CIM is really a "common" information model, it's logically unified and normalized. I was under the impression that DDD was working at the level of Systems of Record