Akka, the Actor model, Scala ....

[Douglas Gugino]

Pardon my ignorance on this topic:  in a .Net, C# - kind of a "residual" microsoft shop? - what are some barriers to using the Scala language in parts of our solution?  can the .Net parts be deployed along with the Scalar parts?  - thanks for being more or less kind in your responses.

[Greg Young]

There is akka.net that you may want to look at.

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Peter Hageus]

Since they’re different runtimes, every integration will be out of process.  That’s the trend now anyway, so might not be a problem.

 

Whats your primary motivation for picking up Scala?

 

Like Greg mentioned, akka.net exists.

 

If you want a hybrid, functional-first language, F# is very nice.

 

/Peter

--

[Douglas Gugino]

motivation is : trying to get to "ease of implementation technique"  - and due to my being *only* a domain expert; lack of experience in implementating software developed using the DDD philosophy; the promise of the [process manager] pattern; the benefit of documenting events; the ease of thinking functionally; AND reading books like "Reactive Messaging Patters with the Actor Model - Application and Integration in Scala and Akka" - by Vaughn Vernon ....

[emragins]

The introduction of Java, which scala compiles to, into a .net shop is something that should be considered very carefully and avoided if reasonable. Generally speaking it requires a completely new set of tooling and you will run into all sorts of issues not directly related to "how to we design and write this code".

One of my old jobs tried this and as a whole it was an abysmal failure.. nothing written in java ever got past the prototype stage and meanwhile the business still wants/needs their new features. As a very minor example, I spent a couple days testing out different Java JSON serialization libraries and never even did find one I liked. In .Net I know exactly which library I want to use and how to use it. That's just one very minor thing in the vast universe of building robust software....

[Douglas Gugino]

thanks. akka.net is where I'll turn our attention.  there is a vast universe.  robust (and good enough) software is the goal.  the one thing I'm relentless on is the language of my business and I am amazed at how hard that is for some.  really quite an interesting and frustrating social experiment I'm on. either "I really don't what you call it" or laborious adoption; I'm held 'hostage' at the time to others slow understanding - if anybody is interested I could show them a job posting we have :)

[Peter Hageus]

Sounds like very language agnostic goals to me.

/Peter

[Douglas Gugino]

we need a white board !  the ease of domain specific language is what I'm trying to convey .... oh well... such a social experiment this is !

[Douglas Gugino]

sorry Peter ... I thought you were responding to a 'later in time' post .... maybe I should send myself a message to become more aware .. ha

[Aryeh]

Hi Douglas,

I can see the attractiveness of pursuing Reactive Applications as espoused by the Reactive Manifesto.  Let's be honest it essentially promises a simple way to model concepts:- just model incoming/outgoing messages, state mutation based on the incoming message, and actor supervising strategy.  Your team working on your complex domain just needs to understand and model this, and then you get the benefits of scalability, concurrency, and support for a distributed architecture for free!

Well that's the promise.  But reality is not so simple sadly.

That we reduce everything in our problem under consideration to what is effectively a command and subsequent event, either through an "aggregate-first-architecture" based on eventual consistency, or similarly through "Reactive Architecture" based on Actors, is antithetical in my opinion to a domain first approach.

I'm not saying that a domain model driven approach applies everywhere.  Perhaps your domain isn't complex or is in computer or data science, rather than business, commerce or industry?  Perhaps it contains a lot of "temporal" concepts, or some other functional or non-functional requirements not mentioned here?

I understand how big the gap is in understanding between yourself as domain expert and your team, and therefore how attractive it is to pursue a solution that sort of says... "you don't need to close that gap!".

Best regards,
Aryeh Hoffman

[Douglas Gugino]

Thanks for your reply ... I really am not espousing using anything, always .... "Always doing anything is stupid" :).   However when, among the "tools in the toolkit" an implementation appears, use it !   Greg's focus on basic composition is encouraging ... however ..... I'm still waiting !  And isn't it interesting that even if there is not a [domain model] the language of the business still is there.  Developers can't use their own words, anywhere ... really ... hmmm.

[Aryeh]

>>> "However when, among the "tools in the toolkit" an implementation appears, use it !"

Sure, if the risk/cost/benefit ratio is understood and in your favor!

>>> "And isn't it interesting that even if there is not a [domain model] the language of the business still is there.  Developers can't use their own words, anywhere ... really ... hmmm."

I didn't quite understand this?

[Douglas Gugino]

Yes to the first point.  regarding the 'own words'; even if it is just "transaction script" over an anemic domain model; or "transaction script" over active record; or "transaction script" over table module; or "transaction script" over nHibernate; the words in the code are the words used in the business you work for (not something that you think is interesting) .... crazy - :)

[Douglas Gugino]

you see I'm fresh out of "Greg's class" ... 

You can still give a name to something !

If something (imho: really rare) is technical - it could be opaque.

Any business dependency must be transparent

In your Command Handlers - bring your dependencies forward - (Business people and) developers need to rationalize what your code does

Use a bootstrap method to hard code all your dependencies, to figure out how everything is wired up

Object oriented is only one viewpoint

The Test as documentation - business needs to read the test

Understand more than one way to do something

The business needs to be responsive; technical people default to attempt to prevent (even if it should be manually compensated for).

Process managers serve to guard against strange failures

Think in 'message' loops

Talk to police officers ! 

[Aryeh]

>>> "the words in the code are the words used in the business you work for (not something that you think is interesting) .... crazy - :)"

Still not really getting your point.  Why is this so "crazy"? But love the enthusiasm!

Even if one represents a problem in different ways, the solution will typically use some of the terminology used in the problem?  Is that surprising?

[Douglas Gugino]

enthusiasm I have plenty of - what is surprising to me is the process of adopting terminology is so awkward.  that is the crazy part, shouldn't be so hard. people fight the power of words ... maybe something to do with the "pride of authorship" and the inability to let go and let the business decide. Or perhaps it is that developers who think like Greg are rare ?  I'm really staying away from the word architect because in my opinion if you can't do, you can't architect?  are the skills of implementation so obscure ?  I know you are all saying - enough already.

[Kijana Woodard]

> Or perhaps it is that developers who think like Greg are rare?

Unfortunately, yes.