purpose of adding events layer in DDD - spring

I was going through with https://github.com/spring-guides/deprecate-tut-web tutorial on Spring. I am new to Spring . I have seen a few small Spring Web MVC tutorials before . Most other tutorials i have seen uses a service layer which is invoked from the web controller. But never have i seen the use of "events" layer as used in this tutorial. Is the layer really necessary, and if so what benefit does it give me ? I am also new to both DDD (Domain Driven Development) and TDD (Test Driven Development), some things just seem really redundant and over-complicated to me in this tutorial .. Can someone explain what is the purpose of this events layer and why should we use it ? Thank you in advance and sorry if it's a Noob question. :)

The purpose of domain events are notify any interested party that something has occurred in one of your domain objects. For example, if you hear a business expert say something such as "when an invoice is approved, release payment", then you probably want a domain event called InvoiceApproved. This way the payment related code can subscribe to that in the application layer and not be tightly coupled to the invoice logic and orchestration. Domain events are a very necessary and very powerful aspect of DDD.

Related

If using Spring MVC, how to move from request-response design to publish-subscribe architecture?

My question raised because I have read some online resources, that claimed that Event-Driven Architecture seems better then using REST
https://solace.com/blog/experience-awesomeness-event-driven-microservices/
So I try to re-design my Rest based application to implement some messaging system, but I am not sure how can it work with MVC
when each services use Rest-API to communicate, then the structure like:
HTML view -> MVC controller -> controller send request Service A -> Service A return response to controller -> HTML view
but if I tried implement publish-subscribe (I am using Spring Cloud Stream and Kafka), I do not understand how can my "correct" user can receive the response. because I think when there are 2 different users:
Please see the image, I am not sure how, after my controller receive the message from the topic, can route to the correct user.
I tried to use "consumer group" but it seems not the solution because it can only specific which "service instance" to handle the message, but here, my MVC application is the service instance but with different connections (different user)
I have tried my best to explain my problem, I am not good in English, please let me know if you need me to express more.

Creating an API for LUIS.AI or using .JSON files in order to train the bot for non-technical users

I have a bot that uses .NET, MS Bot Framework and LUIS.ai for its smarts.
All's fine, except that I need to provide a way for non-technical users to train the bot and teach it new things, i.e. new intents in LUIS.ai.
In other words, suppose that right now the bot can answer messages like "hey bot where can i get coffee" and "where can I buy some clothes" with simple phrases containing directions. Non-technical users need to be able to train it to answer "where can I get some food" too.
Here's what I have considered:
Continuing to use LUIS.ai. Doesn't work because LUIS.ai doesn't have an API. The best it has is the GUI to refine existing intents, and the upload app/phrase list feature. The process can be semi-automated if the JSON file with the app can be generated by some application that I write; however, there still needs to be backend code that handles the new intents, and that has to be implemented by a C# coder.
Could it work if I switch from C# to Node.js? Then theoretically I would be able to auto-generate code files / intent handlers.
Azure Bot Service. Seems it doesn't have a non-technical interface and is just a browser-based IDE.
Ditching Bot Framework entirely and using third-party tools such as motion.ai. Doesn't work because there's no "intellect" as the one provided by LUIS.ai.
Using Form Flow that's part of Bot Framework. If my GUI bot builder application can generate JSON files, these files can be used by Bot Framework to build a bot automatically. Doesn't work because there's no intellect as in LUIS.ai.
Keep using Bot Framework, but ditch LUIS and build a separate web service based on a node.js language processing library for determining intents. May or may not work, may be less smart than LUIS, and could be an overkill.
Override the method in LuisDialog that selects the intent from the LuisResponse, in order to use the my own way to decide the intent (but how?).
At this point I'm out of ideas and any pointers will be greatly appreciated.
First of all, LUIS.ai provides an API that you can use to automatize the training. Moreover, here is Luis Trainer written entirely in Python against the API that just does that.
The easiest one, probably is the one you are describing in #1: you can automatize the training (as explaining above) but you will still have to deploy a new version of the bot if new intents are being provided. One thing is letting users to train an existing model with new utteraces and another completely and different thing is to let them create the model :)
It might be hard to skip having to write the backend code (I wouldn't automatize that at all)
Here is a potential idea (not sure if it will work though). You would need 2 Luis models.
One with your current model, that users will be able to train with new utterances.
The second model, is one exclusively intended to be "expanded" with new intents by users.
If you separate this in that way, you might be able to look into a "plugin" architecture for the second LUIS model. So, your app, somehow, loads dinamically an assembly where the second model lives.
Once you you have that in place, you can focus on writing the backend code for your second Luis Model without having to worry about the bot/first model. You should be able to replace the assembly with the second Luis Model and be able in the bot to detect if there is new version of that assembly and replace the current one in the app domain.
As I said, is just an idea as I'm brainstorming with you. Sounds a bit complex, and it's not addressing all your concerns; as you still will need to write code (which in any case, you will eventually have to do)
I am working through a challenge project (training) to automate the creation of Chat Bots specifically targeted against a Luis.ai model using plain old javascript and web services to Luis.
I looked at the Bot Framework and it's just too cumbersome to automate (I want X number of customers to create a Chat Bot without coding). I also want to add my own type of 'Cards' (html widgets) that do more and can be easily configured by someone with zero coding skills.
Calls to the Luis.ai/Cognitive Services API are made in my code behind and the json response returned to my own rules engine. On the following URL click the LUIS API link on the page to open the Luis API Console where you can test, and train your Model. All the endpoints you will need are here...
https://dev.projectoxford.ai/docs/services/
Based on the various endpoints on that page, you can use WebClient in asp.net to pull back the response. So in my testing I have buttons on a page to push utterances up to the model, pull back entities, create hierarchical entities and so on. Have a look at http://onlinebotbuilder.com to see how an intent of product dynamically inserted a shopping cart.
When your tool is built and utterances start to arrive, Luis.ai will store them and via the Suggest tab (at Luis.ai) it will ask you for guidance...Unfortunately I don't think you could give that control over to your customers, unless they are experts in your domain (they understand which utterance belongs to which intent). You don't need to take your app down, just train it periodically to improve the Model based on your customers input...soon enough you will have your model working well based on your intents.
Hope that helps.

When does it make sense to use Actors in a web application

I have been browsing Typesafe Activator templates. Often in the Typesafe templates (Reactive Stocks / Maps / *) I see an actors folder within the app folder. Obviously, this is supposed to hold actors, but how would one add actors to a Play application. I know that Play is an MVC framework, and that means:
Models act as templates for structured data, and are used for interaction with the database and passed to views
Views are web pages, and typically can have data injected into them.
Controllers contain business logic, and may bridge models and views
If this is so, what are Actors for? What do they add that Models, Views, and Controllers do not provide? What would be some practical uses of Actors while developing reactive web applications?
EDIT
While reviewing Play documentation, I have found that Actors may be useful for scheduling. Are there any other uses for Actors?
The Play Framework uses controllers to handle the requests. The controller fetches the data from the models and transforms/filters/modifies it, so that the views can handle the data. The controller also contains the whole business logic.
The way the Play Framework is designed, those controllers should handle those requests either really quick, or return an asynchronous Promise. This is where the actors come in handy. If you have requests which take a long time to compute, you can use an actor to handle the request asynchronous. Have a look at the documentation.

What are the good practices and useful design pattern to provide an API which supports internationalization?

Given an existing API working well with the usual mono-locale approach, what are the steps one should follow to turn it into an internationalized version, which enable user to send/receive keys/values in localized versions?
End user interface internationalization is a well covered topic.internationalized. But how can it be pushed further on request and response? If someone hits an API and wants the response in German how can I do so ?
It is kind of tricky answering without any kind of context, or sample API, or a even a high-level description of what your API does.
But in general it is best to separate your APIs into several layers.
The core functionality and data at the application level should be locale independent, something like this http://mihai-nita.net/2005/10/25/data-internationalization/
Then you would have the presentation layers, with things like date/time/number formatters, collation, localization, etc.

Session State with MVP and Application Controller patterns

I've created an MVP (passive view) framework for development and decided to go for an Application Controller pattern to manage the navigation between views. This is targeted at WinForms, ASP.NET and WPF interfaces.
Although I'm not 100% convinced that these view technologies really swappable, that's my aim at the moment so my MVP framework is quite lightweight.
What I'm struggling to fit in is the concept of a "Business Conversation" that needs state information to be either (a) maintained for the lifetime of the View or, more likely, (b) maintained across several views for the lifetime of a use case (business conversation). I want state management to be part of the framework as I don't want developers to worry about it. All they need to do is to "start" a conversation, "Register" objects and the framework does the rest until the "end" a conversation.
Has anybody got any thoughts (patterns) to how to fit this into MVP? I was thinking it may be part of the Application Controller responsibility (delegating to a Conversation Manager object) as it knows about current state in order to send the user to the next view.... but then I thought it may be up to the Presenter to start and end the conversation so then it comes down the presenters to manage conversations and the objects registered for the that conversation. Unfortunately that means presenters can't be used in different conversations... so that idea doesn't seem right.
As you can see, I don't think there is an easy answer (and I've looked for a while). So anybody else got any thoughts?
The classes needed to support a Business Conversation should reside in a presenter if it only involves the User Interface. Otherwise it should be in the Model and controller from the View to the Presenter to the Model. With information about Business Conversations flowing the other way. I suspect is something that can reside just in the Presenter.
Since all Views have access to the Presenter you then have the ability to structure the objects supporting the conversation so that they can be maintained across several views.
Remember Views are a window into what data resides in your software. They did little other display data and pass user interactions back into the presenter which does the logic.

Resources