The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Lucian Enache wrote:Hello,

Since akka-http, typed actors and reactive streams are part of the akka eco-system, I wanted to know if you
plan to add chapter that will discuss these modules too.

Hi, we are not planning on adding any additional chapters at this point in time.
66579 wrote:Hi,

Is this book going to be written? I am asking for me to know should I purchase it or notsmilie

Duncan and I are 100% committed to finishing this book and it is a top priority. We write each day and want to make sure we get things right before releasing to MEAP. I really wish I had more time to write but obviously reactive/akka/scala is a lucrative trend and will be for years to come and as such I am buried in full time client work.

Some people think implementing your domain as an actor is an implementation choice/detail. I consider Akka actors as much a part of the Scala language as anything else, including classes and traits. I have not seen much value in implementing my domains as a trait and wrapping them in an actor. I feel it is a pointless exercise but again, just my opinion.

337948 wrote:Hello,

at some point of page 76 you mention that you will translate the concept of factory and repositories to an Actor-based idea, supposedly in section 4.2, but neither factories nor repositories are mentioned in such section.

Besides this, excellent work. I am looking forward to the next chapters even tho I'm slightly worried that they might never see the light.


We decided not to address Akka in that chapter so I'll remove that reference. Thanks.
311926 wrote:Please roll out the next chapters asap, readers momentum is lost with the delay.


We apologize for the delay as life and work reared their ugly heads. We're getting the next 3 chapters ready to go in the next few weeks so bear with us and we appreciate your patience!
343129 wrote:That's great Sean. Will the running domain have multiple bounded contexts and show the progression of reactive workflow between them (ex: like orders to invoicing to fulfillment)?

In order to demonstrate eventual consistency it most surely will.
343129 wrote:Hi Susan

Congrats on the great book, I'm enjoying the read and liked how you explained boundary context and behavioral aspects of DDD.

From my experience, I think the most common domain models developers develop in day in day out are micro ERP models in context. Obviously the context and workflow of how a business processes sales, orders, invoicing, fulfillment and shipment vary, depending on if the business trades goods, service or both to consumers. So, such businesses can be retail, logistics, finance to investment companies, but in each case the context of items ordered and how they are processed and fulfilled/delivered vary, but the process workflow patterns logically similar.

Would you be so kind as to use a micro ERP contexts (sales, order, invoicing, delivery) in your domain model in Part 2. It would allow developers to more easily relate to and understand what you are trying to explain, and better grasp the advantages of Akka messaging, DDD/CQRS and event sourcing. The workflow between the different micro ERP contexts as reactive events would also be more easily understood and allow developers to more readily apply such solutions without much of a context switch.

Success Susan


Thank you for your input. We are planning on a sort of running domain example and will consider more of an every day domain for the remainder of the book.

We are a teeny bit behind on chapter 3 but chapter 4 is ready and is with the MEAP folks now to be made available. Duncan and I will then work together on finishing up on 3 as soon as possible before we move onto chapter 5. Thanks for your patience!
338343 wrote:p 32
This intro text is not very clear. The remaining of the text is a bit more. However, I don't get below the difference between command and event. Is that a question of perspective. You send command and receive events?
It is clearer at the end of the section (page 35), but could already be unveiled more explicitly in the coming paragraph.

just my 5c

Thanks for the feedback. Command is of course the intention to mutate state, and the event implies the state has been mutated but we'll go over that again for clarity.
16473 wrote:On page 31, in the callout "How did Akka get its name?" you mention that it is a *mastiff* (a compact group of mountains)...
I think you meant *massif*? As far as I recall, a mastiff is a large dog smilie

Great book BTW, can't wait for the next lot!!!

Thanks! I didn't know what massif was until now but I sure do know Mastiff. We'll get that corrected.
nresni wrote:Hi,

I will begin a new project and I would like to be reactive ! smilie

You recommend to start directly with akka persistence, but in typesafe documentation, akka persistence is experimental, so my question is: Is it ready to go in production ?

Thanks for this book !


Nresni, the journal aspects of akka-persistence are as production ready as "experimental" gets in my opinion. What you should be careful of is how you model your CQRS read side as that part of akka-persistence is still evolving. I plan on rolling my own and simply publishing events and using listener actors on the read side as I've done with much success in the past, at least until the Akka team comes up with a better design.
MaurĂ­cio Fernandes de Castro wrote:Yes! Despite I do not have any previous CQRS experience to devise the full impact of such decision, it seems to me very appealing to separate strategies (and jvm's) to query and update the persisted state of a system.

In addition, the project I now plan to convert according to the "Reactive Manifesto" was open sourced in 2004 to incentivate best practices within our local ITC cluster. I expect to have other teams learning from my experience in a near future, including CQRS/Event Sourcing.

Thanks for the help,

MaurĂ­cio Castro

Ok the reason I asked is that if you are planning on going the CQRS route then that migration to Slick doesn't really buy you anything in the long run since you will likely be using akka persistence to store events only, no more CRUD. Your migration path sounds like it would best be a full rewrite using akka persistence.

I would suggest taking a single area of your application or a single bounded context (domain driven design) and migrate that first. You application will eventually be a set of completely decoupled microservices.
Hi, question: Are you planning on going CQRS/Event Sourcing as well?
Lucas Arenas wrote:Hello, mi name is Lucas. I am very excited about the book, so I want to know when do you think the next chapters will be published?

Thank you.

Hello Lucas. We are planning on chapters 3 and 4 to be made available in the next couple of weeks. We've written them both and are just polishing them up. Thanks.
I'd like to thank you for purchasing our book, which I know will make your distributed application development much easier. Duncan and I researched long and hard and consulted with some of the smartest people in technology in order to arrive at a set of software practices and tools that would be responsive and distributable and little did we know we were building one of the first reactive architectures in the wild. When we delivered our first modules we were astounded that an architecture that traditionally had been such a challenge was actually a pleasure to build and maintain not only worked but delivered an amazing user experience across the board due to our message-driven, decoupled approach.

Please feel free to make comments or suggestions for improvements we can make, you'll find ready access to both Duncan and I on this forum.