I'm trying to create an application using the knowledge i;ve learnt from Domain Driven Design.
My issue is that in my application I need to be able to create a new customer capturing the customers address, phone number, email address etc, would I just use the standard CRUD style here as this isnt really a task based action?
If all your application is ever going to do is to store customer data in a database, it's probably much better to use a simple CRUD style application. If the customer entry is just part of a bigger application, then it's perfectly reasonable to have a form to enter customer data (such as name, address, ...) - the data has to be entered somehow.
Just be aware of the differences between task-based and CRUD style forms: Say you'd want a customer to be flagged as verified, and for you have a state on the customer that can be "NEW" or "VERIFIED". In a CRUD-style application one would simply use a select box with the two options "NEW" and "VERIFIED" that changes the customer's state field. In a task-based UI you'd have a button/link in the customer form that reads "verify" and starts the "verification task", e.g., by sending a "verify customer" command to your domain layer.
Note that domain-driven-design is orthogonal to the concept task-based actions. They play well together, particularly when one uses CQRS, but they can both be used independently of the other.
Related
I have a question about the integration events used in a microservice / CQRS architecture.
The payload of the event can only have references to aggregates or can it have more information?
If only reference ids can be sent, the only viable solution is to bring the rest of the information with some type of call but the origin would have to implement an endpoint and the services would end up more coupled.
ex. when a user is created and the event is raised.
UserCreated {
userId
name
lastname
document
...
}
Is this correct?
If only reference ids can be sent,
Why would only that be allowed? I have worked with a system which was using micro-services, CQRS and DDD(similar like yours) and we did not have such restrictions. Like in most cases it is: "What works best for your application/business domain". Do not follow any rule blindly. This is perfectly fine to put other information in the events Payload as well.
the only viable solution is to bring the rest of the information with
some type of call but the origin would have to implement an endpoint
and the services would end up more coupled.
This is fine in some cases as well but this brings you to the situation to have additional call's after the event has been processed. I would not do this unless you have a really heavy model/models and it would affect your performance. For example if you have an event executed and based on userId you would need to load a collection of related objects/models for some reason. I had one similar case where I had to load a collection of other objects based on some action on user like event UserCreated. Of course in this case you don't want to send all that data in one Event payload. Instead you send only the id of the user and later call a Get api from the other service to get and save that data to your micro-service.
UserCreated
{
userId
name
lastname
document
... }
Is this correct?
Yes this is fine :)
What you could do instead:
Depending of your business scenario you could publish the information with multiple events with Stages and in different States.
Lets say from UI you have some Wizard-like screen with multiple steps of creation. You could publish
event: UserCreatedDraft with some initial data from 1st Wizard page
event: UserPersonalDataCreated with only part of the object related to private data
event: UserPaymentDataCreated with only the payment data created
UserCreatedFinal with the last step
Of this is just an example for some specific scenario which depends on your use case and your Business requirements. This is just to give you an Idea what you could do in some cases.
Summary:
As you can see there are multiple ways how you can work with these kind of systems. Keep in mind that following the rules is good but in some cases you need to do what is the best based on your business scenario and what works for some application might not be the best solution for your. Do what is most efficient for your system. Working with micro-services we need to deal with latency and async operations anyways so saving some performance on other parts of the system is always good.
We have an application in which we will be collecting addresses from users. In the current implementation, we are using a live agent to do this. Some users, when prompted for a final billing address, will say things like "Just use my billing address" or "same as my current address". THe new implementation will be a chatbot to try and fulfill some of these requests before they get to an agent.
We do have this information available via API lookup, I am asking more from a design perspective how to let our handler app (usually an AWS lambda) know that we need to do the lookup before we prompt to confirm fulfillment.
A few things I thought of:
Train the NLP to detect strings "current address" and "billing address" as Address entities
Create a new intent for utterances like these and handle them separately
Create a new entity type in the current intent (eg, not postalAddress) for utterances like these and handle them as part of the same fulfillment
Simply re-prompting the user, or asking them to state what their address is
I am just looking for the most pragmatic approach here, as this problem is different from most others we've solved.
I had a similar use case, and after investigation found that option 3 is the easiest way to handle this.
You can add a validation hook that fires when the new slot is populated. This hook can populate the value of the postalAddress slot with the associated address. This way you can keep the postalAddress slot as a required slot, without having the user manually state the address.
You can also have this validation hook fire on the population of postalAddress and add some manual testing for billing and current, but this felt to me like a manual work around for something that should be automated by Lex.
I'm thinking to use DDD for our next application. I have already found a lot of interesting papers and answers but cannot find a solution to my problem :
We have an SOA. architecture where some services are known as master of their datas. That's nice but I can't figure how to use them nicely with DDD.
Given a service "employees" who is the master of the Employee datas, it is a crud over a couple of simple values (first and lastname, birthdate, address).
My new app, should track the trainings offered to those employees. So I have the concept of Participant, a Participant has the same values as an Employee plus a list of trainings and a skill.
We can suppose that the "trainings" applications has a database with a table of participants that contains a participant_id, skill and one employee_id used to retrieve the first and lastname.
Am I correct ?
But now, which component may I use to call the "employees" service ? Is it the ParticipantRepository so that when I get a participant I have is names. Or is it the application service who complete the Participant datas before using them. Or may I explicitly call the employees service when needed ?
Thanks a lot.
In your training application (I mean in the domain of your application) the concept of an employee might not exist as other than an external reference. As you correctly said, that will be a Participant.
I understand that you need to get some data from the employee service to populate the participant. I can think of few options.
1) ParticipantRepository builds a Participant, which is an aggregate root, some of that data might be in a PersonalDetails value object. This value object is constructed by calling the employee app. This approach is easy, but might not be the best. This is the approach you mentioned, where the ParticipantRepository calls an interface PersonalDetailsService and the implementation of that interface does the actual call to the Employee service. In this way, your domain has no idea that is dealing with employees, as it only sees PersonalDetails.
2) Eventual consistency by replicating data from the employee service: If the employee service can send a notification when an employee is updated (e.g. via messaging) you can listen to those events and have a read only copy of the data. The benefit of this is that your app will work even if the employee service goes down. The problem is that you might need to build something to re-send data that might have got lost.
Both of these approaches are explained quite well in the book Implementing Domain-Driven Design
I am developing a Rest API using node js, mongo and express as technologies. My models include users, venues, etc. In addition each user has states. Examples of states could be when a user signup the first state is 'new_user', after one week the state must be 'first_week_user' and so on.
The purpose of these states is to notify the user according to his or her state. For example if a user like a picture and the user is in the first week (he has the 'first_week' state) so an email must be sent to him. I am in the design stage right now, so I want to know if somebody had to face the same issue before.
The design that I have in mind is to put a notification_profile inside the user object and using a cron job to check the state and the actions of the day and according to that send the emails/push notifications.
What do you think? Are there a better option? e.g. I can have an email API and queue the emails hitting this API. Do you know where I can find information about design patterns facing this problem?
Thanks a lot for your help.
Without more detail, this sounds like you need the Observer pattern.
Essentially, your Email component would subscribe to each Person object's like(photo photo) event, and either execute an email-send job immediately, or schedule the job to run later, as part of a batch.
One way to specify the state transitions would be as a hierarchical state machine. See http://www.eventhelix.com/realtimemantra/hierarchicalstatemachine.htm#.VNJIflXF--o and http://en.wikipedia.org/wiki/UML_state_machine
I don't have a good node.js example but here's a C# implementation that also includes the concept of timed events. Essentially the state machine keeps track of a NextTimedEventAt so you can efficiently pull it back out of a database at the right time to fire a time-based event.
Actions happen on state transitions: as you enter a state or leave a state.
Let's assume there are two domain entities:
UserImages with methods addNewImage(), removeImage($imageId), getImages($from, $count).
UserProfile with fields name, age, mainImageId, etc.
Following functionality is desired inside the domain: when application layer calls UserImages -> addNewImage(), UserProfile -> mainImageId is set automatically in case it was empty.
So, what is the best way and best place to implement an in-domain over-entity business logic? Domain events with observing services, referencing special services from the entities, or somewhat else?
I create all the entities using a some kind of factory, i.e.
$userImages = Domain::userImages($userId); // getting an instance of UserImages
$newImageId = $userImages -> addNewImage(); // adding a new image
I also should mention that I will have a lot of logic like described above in my project.
Thank you very much for help!
First off, as specified in your other question, UserImages is not itself an entity. Instead, there is likely an entity called UserImage which refers to a user's image, singular. A UserImageRepository can then provide access to all images associated with a user, using pagination where necessary.
Now, the use case is:
When a new user image is added, if a user's profile image is not set,
set it to the added image.
The term when indicates a domain event. In this case, the event is UserImageAdded. The bold if and the subsequent set represent the desired behavior in response to the event.
To implement this use case, an event must be published when a user image is added and a handler implementing the desired behavior must be subscribed to this event. This linked domain events article provides a sample implementation in C#, however the concept can be easily ported to PHP. Overall, the required components are:
An application service which handles the adding of user images. This service will publish the event.
A domain event publisher which is called by the application service and allows decoupling of publishers from subscribers.
A domain event handler which handles the UserImageAdded event and invokes the desired behavior.
User sounds like Aggregate for me (it's difficult to give you an opinion without context :) ), but it can solve your problem.
If Profil and Images are differents bounded context, may be you can use Domain events (it's helpful for cross bounded context communication)