When we first began using AKKA we had a similar approach and decided to put
all the business logic in a service layer. This is a pretty standard Spring
practice and it made testing a doddle - and also meant we could start
writing the logic before we'd confirmed our favourite AKKA architecture.
EG:
Actor:
@Inject
MyBusinessService service;
onStartup(){
StaticInjector.get().inject(this);
}
onReceive(Object msg [Really just a json String]){
persistAsyc(msg, service.process(demarshall(msg));
}
Think of that service.process method much like a struts Action - in that
the msg likely contains a method="updatePrices" bean="someNewPrice" much
like a Form would in Struts.
This is the side on which we receive a message. In cases where we want to
send a message - we then used a utility which encapsulates all outbound
communications. (IE One place which deals with asking and telling things
and if we switch to JMS communication or HTTP Webservices we could have
done it in these 2 places).
Our actor layer was relatively clean and just handled persistence,
sharding, failure and communication logic.
In the end however we found it far more powerful to be able to use AKKA
features directly throughout business logic and abandoned this approach -
This was made easier because by this time we'd learned the ins and outs of
AKKA much more than when we first embarked on the project and so our fear
of it as a 'new thing to us' went down drastically.
Thanks,
Dan
On Friday, 6 November 2015 03:39:33 UTC, Chinmay Raval wrote:
>
> Thanks Ryan.
>
> Idea was to keep actor infra separate from domain. Also dont want to
> depend on actors, in future we should be able to migrate the infra from
> actor to something else without touching the domain.
>
> On Thursday, 5 November 2015 22:58:01 UTC+5:30, Ryan Tanner wrote:
>>
>> That sounds like it may have the potential to violate actor
>> encapsulation—actors should only be created by the ActorSystem itself. It
>> would depend on the exact implementation but that sounds worrisome to me.
>>
>> Why not just use composition? Let your actors contain and manage
>> business service objects.
>>
>> On Thursday, November 5, 2015 at 3:04:27 AM UTC-7, Chinmay Raval wrote:
>>>
>>> Hi,
>>>
>>> I am using Java 8 with Akka 2.3.12 for an enterprise application.
>>>
>>> To keep business logic and infrastructure separate, we are planning to
>>> use java dynamic proxy that convert business services into akka actors in
>>> the run time (with help of spring).
>>>
>>> I just want to confirm is this the right way to achieve separation or
>>> there is some better way available?
>>>
>>> Thx,
>>> Chinmay
>>>
>>
--
Notice: This email is confidential and may contain copyright material of
members of the Ocado Group. Opinions and views expressed in this message
may not necessarily reflect the opinions and views of the members of the
Ocado Group.
If you are not the intended recipient, please notify us immediately and
delete all copies of this message. Please note that it is your
responsibility to scan this message for viruses.
Fetch and Sizzle are trading names of Speciality Stores Limited, a member
of the Ocado Group.
References to the “Ocado Group” are to Ocado Group plc (registered in
England and Wales with number 7098618) and its subsidiary undertakings (as
that expression is defined in the Companies Act 2006) from time to time.
The registered office of Ocado Group plc is Titan Court, 3 Bishops Square,
Hatfield Business Park, Hatfield, Herts. AL10 9NE.
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
