So I'm a bit new with CQRS (not totally a beginner though). I'm trying to understand the best practices when it comes to aggregates interaction. I read a bit about using Integration Events (instead of Domain Events) in these situation, also a bit about Domain Services (that would supposedly link the 2 aggregates) but couldn't find any good definitive answer anywhere (especially not on the axonIQ Getting Started guide
Also another not too related question is that in layered architecture usually we have the controller directly linked to a service and this service can interact with other services (or repos) while with CQRS the controller is usually sending a command to the aggregate. So if my api call needs to interact with 2 aggregates do I have to build a middle-man service that would send commands (or listen to events) from the 2 services?
The interaction between components in a CQRS system can happen on a couple of levels.
On way to think about it is as Maxime suggest, with Microservices, very clearly showing the messaging focus of it all.
Regardless though, this can just as simply happen within one Application/Monolith which has several Aggregate types that together need to trigger some operation.
I feel that Maxime is providing you the answer you need. The Aggregate instances which you send commands to, act on their own and do not tie in to one another directly, at all. You'd thus react on the events as the driving force the start an interaction between both.
You can either do this by having a Event Handling Component which listen to both the events and performs the business transaction you're dealing with.
If the business transaction is a little more complex, looking at Saga's might be a good start.
Lastly, you state the 'Getting Started' part of the Axon Reference Guide is not clear about this topic. I think that's a valid conclusion, as from Axon's perspective this is not part of the Getting Started. Take a look at the Saga portion of the guide to get an idea of the interaction between Aggregates and/or Bounded Contexts.
If you think of this in term of microservices (which is a philosophy that fits CQRS very well) you should have one aggregate for one microservice. So you can't communicate between aggregates in memory because they're not part of the same process. A good way to do it is by using events that you can publish in a event bus. So the client send a command to "aggregate A" using the API of this microservice (i.e. "microservice A") (or maybe an API gateway). Then "aggregate A" is saved and the events generated by "aggregate A" are published to the event bus so that some process (aka. event handler) in "microservice B" can catch the event(s) and send the appropriate commands to "aggregate B".
It's just one way to do it there is many more and it can be very more complex than that, but I hope it's helping getting the big picture.
Related
I know that the spring DSL can be a very powerful tool but, how do you know how to build one from scratch depending on your different needs? When I see an integration flow online it's easy to follow and I can generally make sense of the flow. However, when building something a little bit more custom how do you know what goes into the integration flow? Im new to spring integration and the Spring DSL in general so it would be useful to know where is a good place to start and what is the best way of thinking about things when it comes to spring integration.
I treat this question as a fundamental matter familiarity. Consider to start from Enterprise Integration Patterns, learn what is Message, Endpoint and Channel. Then you re-think the logic of your application as some service calls, which could be initiated by messages sent to endpoints for those service activator. When it is all good for you, you start combining the logic into a flow, when an output channel of one endpoint becomes as an input for the next one. Essentially this is exactly what is going on underneath with the mentioned IntegtionFlow abstraction. Then you go further and determine for your self that several flow could be connected via the same not one time already mentioned channels. It is not quick one stop shop, but it is fun to rethink the logic of your application as messaging exchange.
See more info in docs: https://docs.spring.io/spring-integration/docs/current/reference/html/messaging-endpoints.html#messaging-endpoints-chapter.
The Java DSL with its IntegationFlow definition is just a higher level of abstraction on top of endpoint implementations for specific EI patterns.
I've got one question concerning microservices architecture. I am designing a system based on microservices. I've read few articles and I think I understand the idea. However, I don't how microservices should communicate with each other while they have separate business responsibilities....
What I mean is that if I have a system for booking train tickets, I would divide backend application into modules:
Client (login,logout,registration)
Reservations (booking a train seat for user,getting all reservations for user)
ConnectionsDetails
(searching for connections,getting connection details)
Trains
(information about trains- seats number,class etc.)
Now, I can only think that if user search for connections module ConnectionsDetails communicate with Trains module and ask about particular train details. But how could other microservices communicate? If user wants to login - she/he asks directly Client module, if she/he wants to get all her reservations - asks Reservation module DIRECTLY etc...
So my question is, how should modules communicate if they do different things? I'm sorry if my question is trivial or stupid, I'm just starting with microservices.
EDIT:
I didn't mean what tools could I use for communication. My question is about logic. In the example I showed, why one microservice could ask another microservice about sth if client can directly ask the another one? As I said earlier, how they should communicate(about what should they ask each other exactly) if they do separate things?
To find the right contexts, borders and communication channels is imho one of the most difficult parts of a microservice architecture. It is about finding the data you need, how the relationships are and which service is responsible for what (responsible means the only one allowed to change it). Have a look at the Blog from Martin Fowler.
Microservices is not modules. Each service should be an independent service regarding development and deployment. And yes, they may communicate to each other but a client may also communicate to them individually. The Microservice approach is also about using the right tool for the problem. So each service can be implemented in a different programming language. They can use different kind of storage like RDMBS, NoSQL or Key-Value store. An they will be scaled individually - many instances for ConnectionsDetails and fewer for Reservations e.g.
What will happen if one service is not available? Each service should be as fault tolerant as possible and try to decrease it's service gracefully if nothing else is possible. You should think about minimising the needed communication between the services by choosing the right borders, make data independent and maybe introduce caching. Don't forget about the CAP theorem, a microservice approach makes it more visible. Here are some slides about resilience that may help. Do not share the same database or replicate everything between services.
"how should modules communicate if they do different things?". You should choose a language independent way of communication and depending on your problem a synchronous or asynchronous method. As a language independent format JSON or XML are most common. Synchronous communication can be based on REST, asynchronous communication on messaging. The authentication ("Client") is typically a REST service, sending the booked tickets via Email is more a message driven asynchronous service.
As I think that is a major question about classical SOA vs. Microservices.
I guess you can find many opposite answers to that.
so IMHO:
If in your architecture services communicate each other they are not microservices, since there are dependencies between them.
Instead of that if each microservice has all needed functionality (or say components) and do not depend or communicate to each other then they are microservices.
So in your example you have 4 components.
Clients, Reservations, ConnectionsDetails, Trains.
But, microservices may not necessary match them exactly.
As you said "if user search Connection"...
So "Search Connection" that is microservice which includes all needed components (Client, ConnectionDetails, Trains) and is independent.
And finally, how components (not microservices) will communicate to each other is up to you. With microservices you have a luxury to use straight POJO with no transformations, protocols, transport layers at all.
Or you can make communications more formal, which push you back closer to classical SOA rather than microservices.
I have a situation where an application has a list of values, for example, a list of books, that changes from time to time. It also has a REST endpoint where this information is published.
There are several other applications that consume this information, and they should be aware if any of the books on my application changes.
Would the reactive style be adequate to this situation? At first, I thought so, based on the Observer pattern. But would this be a good approach, considering the applications involved only exchange information based on web services?
I also looked at retrofit, that could transform the endpoints, into java interfaces. But all the examples I found, were somehow related to android applications.
So, would this approach be advisable in this scenario? If it is, can someone recommend a book, or any kind of resource?
EDIT:
Since I will have an endpoint that publishes books, should I turn it in to an Observable, that when gets another book available, notifies all the subscribers of this event, and that would in turn decide if they should or not do something?
If so, how would a client, it can be for example, and angularjs app or another java application, subscribe to this observable?
I hope I could make myself a little bit more clear.
I think you are mixing up the Rx programming with a network problem. If your server sends data over the network at X interval of time then as #TheCoder said you can listen for changes on a socket and trigger an event on your rx stream with the help of a PublishSubject. But I think that the real issue lies in the way your data are sent by your server.
If you have to query your server to know if your list of books has been updated it is not very effective to trigger such calls when your goal is to have a real time update. In these type of scenario a Publish-Subscribe pattern is more appropriated where your client just act a receiver and can update itself as soon as your server push new values (a new list of book in your case). You can find tools like pubnub or the MQTT protocol to achieve such things.
For you to understand quickly how this system works you can look at this.
I am building a social networking kind of site. I am looking for a
highly scalable free and open source framework for event processing.
e.g when a user does some action on website, it would trigger an
event of a particular type for backend. A number of listeners will be waiting
for this type of event and as soon as those listen to event, they would do
some application logic for that event e.g. sending emails/sms, or data mining or start a bulb
.. literally anything.
Does anyone know any such framework? Let me know if I am not clear enough.
Thanks,
Nilesh
Look at the Axon framework.
Axon Framework helps build scalable, extensible and maintainable
applications by supporting developers apply the Command Query
Responsibility Segregation (CQRS) architectural pattern. It does so by
providing implementations of the most important building blocks, such
as aggregates, repositories and event buses (the dispatching mechanism
for events). Furthermore, Axon provides annotation support, which
allows you to build aggregates and event listeners withouth tying your
code to Axon specific logic. This allows you to focus on your business
logic, instead of the plumbing, and helps you to make your code easier
to test in isolation.
JMS provides this. Send a message to a topic, and all the listeners on that topic will receive the message.
There are several free implementations available (ActiveMQ, JBoss Messaging, etc.)
Maybe Hazelcast is interesting for you, e.g. it offers distributed listeners and events among other interesting features for distributed applications like distributed maps, locks, distributed topic for publish/subscribe messaging etc.
Hazelcast allows you to register for entry events to get notified when entries added, updated or removed. Listeners are cluster-wide. When a member adds a listener, it is actually registering for events originated in any member in the cluster. When a new member joins, events originated at the new member will also be delivered.
Building a client-side swing application what should be notified on a bus (application-wide message system, similar in concept to JMS but much simpler) and what should be notified using direct listeners?
When using a bus, I always have an unescapable feeling of "I have no idea who uses that and where". Also, no set order, hard to veto events, hard to know exactly what's going on at a set time.
On the other hand, using listeners means either directly referencing the source object (coupling) or passing the reference through myriad conversions (A--b_listener-->B, B--c_listener-->C only because a needs to know something only C can to tell, but B has no interest in).
So, are there any rule of the thumb regarding this? Any suggestion how to balance?
In my experience, trying to make Swing do something it wasn't designed for, or doesn't want you to do, is extremely painful.
I would go with the simplest thing that would work; keep your code clean, do it the "Swing Way" until you start seeing problems.
Event buses are very, very useful tools for providing decoupling in certain architectures. Listeners are easy to implement, but they have significant limitations when your object and dependency graph gets large. Listeners tend to run into problems with cyclic dependencies (events can 'bounce' in odd ways, and you wind up having to play games to ensure that you don't get stuck. Most binding frameworks do this for you, but there's something distasteful about knowing that listener events are shooting off into a million places).
I make this kind of decision based on project size and scalability. If it's a big app, or there are aspects of the app that can by dynamic (like plugin modules, etc...) then a bus is a good way to keep the architecture clean (OSGI-like module containers are another approach, but heavier weight).
If you are considering a bus architecture, I recommend that you take a look at the Event Bus project - it works very well with Swing and provides a robust, out of the box solution for what you are asking about.
The convention in Java Swing is to use listeners heavily. Sticking with the convention improves maintainability but stifles innovation.
I've not encountered the bus approach in Swing, but I find it interesting.
Well, I can imagine the approach where models are updated using BUS like system and events from models are delegated using listeners. Simple scenario: I got server side which represents producer of data. Then on client side a got consumer interface which consumes all incoming messages and transform them into my internal messages/DTOs and push them into bus which distributes them into application model(s). These model process incoming messages and decide to notify interested components using listeners.