These are chat archives for petabridge/akka-bootcamp

Mar 2015
Aaron Stannard
Mar 08 2015 03:30
@ralfw that's a great question - honestly it's largely driven by the single responsibility principle and consistency boundaries, like @rogeralsing said
In the Unit 2 and the Unit 3 (coming soon!) code samples, WinForms enforces some hard consistency boundaries around the UI thread.
But aside from that, everything else is driven by consistency boundaries with respect to an actor's internal state
some actors will be pretty stateless, I.E. the performance counter actors in Unit 2
but others, like the coordinators in Unit 2 and Unit 3 carry a lot of state but don't do much actual work
those coordinator actors are responsible for maintaining a consistent view of the state of the "job" being formed by several actors
so you want to put a box around that and make it that actor's job to serve as the aggregate for the others
in a much larger example, like the ASP.NET + SignalR + Akka.Cluster one I've finished but am still documenting
you might have multiple areas where you need to define consistency boundaries for a large job
(in this case, a distributed web crawl)
Ralf Westphal
Mar 08 2015 07:25
The SRP… yes, sure, that’s an important driver. But then: What is a responsibility? :) I define it as a set of traits with high cohesion. And the cohesion is high because the traits are more likely to change in unison. And since „trait“ is a pretty general term is like to talk more of aspects_ than _responsibilities.
You can change aspects of something independently.
So the question is: How to find aspects? How to draw a line around a couple of traits to put them into the same set, to call the an aspect?
Ralf Westphal
Mar 08 2015 07:32
There are a couple of hard aspects which can be spottet just by looking at code (or a design); you don’t need to understand the domain even. I’d say, that’s state and APIs. Functionality accessing the same state belongs close together (to encapsulate the state). That’s what you mean by consistency boundary, I guess. And functionality using the same API (eg. WinForms, file IO) belongs close together.
Also I view coordination/integration as a hard aspect. Putting stuff together to form a larger whole is a responsibility of its own.
Ralf Westphal
Mar 08 2015 07:42
Aspects can be encapsulated in actors or „mere“ objects. But when to choose which? Maybe that’s my question.
Why are there ButtonToggleActors in unit 2? Simple objects would have done, I guess.
The ChartingActor is responsible for syncing performance data with the Windows thread. But why does it know about WinForms as an API? Why isn’t that encapsulated in the WinForms dialog?
Ralf Westphal
Mar 08 2015 08:20
When should responsibilities be encapsulated by actors? When are objects enough? Also: Are actors means to fulfill efficiency requirements (performance, scalability)? Or are they also means to increase evolvability?
Aaron Stannard
Mar 08 2015 18:57
@ralfw these sound like the programmer equivalent of Zen Kōans :p
And what excites me about the things I'm hearing from this bootcamp is that people like you and the other attendees will draw your own conclusions and different ways of thinking and designing than what's been shown to you here
because there's a million ways these applications could be designed - I went with a style that I'm comfortable with, which is just encapsulating everything into actors
but that's certainly not the only way and probably not the best way either :p
but it's a radically different way than traditional approaches - and once that clicks we can start to see lots and lots of different and better ways of designing applications than we did before
if you were to write a blog post proposing a different way of designing one of these samples, we would give it some love ;)
Ralf Westphal
Mar 08 2015 20:36
i’m always in for a some more love :-) so let me ponder this a little...
Andrew Skotzko
Mar 08 2015 21:34

@ralfw great questions and as Aaron said, it’s awesome to see you and others here asking them and really grokking / digging into the model, gievn what a change it is from business as usual.

We do not hold that what is in the bootcamp samples is the only way, or even necessarily the right way—just the way that made sense to us when we were designing the exercises to get the points across that needed to be made.

We’re totally in favor of the discourse outgrowing bootcamp and hope it does. As Aaron said, please feel free to write more about it and we’ll happily give it what help we can