I want to create simple sport bookie system. I want to use some sort of DDD design and clean architecture design. Lets say that system will have Event aggregate that will contain different event information and list of betting markets inside it. The trouble i have is to model Market entity itself. If we look at the typical pre-match event UI on the typical bookie site we can see a lot of betting markets there. Each of them has different structure. For example 1_x_2 market, over_under market etc. The question is what is the possible options, how i can model this betting market entity?
Typical sport betting event
Related
I'm designing meal planner app. I want it to has:
typical cookbook with recipes (recipe can be added to cookbook by user, it contains list of ingredients with thier amounts, servings amount, calories amount calculated based on ingredients, ingredients can be added to shopping list and recipe itself can be added to meal plan). Recipes can be searched by some filters like cuisine type etc.
meal planner - modifiable list of recipes for every weekday
ingredients catalog - ingredients can be searched by filters, every ingredient some values e.g. calories. Perhaps it would has calculator for measurement (something like how many grams is in spoon of flour)
shopping list - list of ingredients added from recipes or manuanly by user, they can be removed and their quantity can be modified
As for architecture I want it to be microservices based app. I have read some books like Building microservices, Domain-driven-design quickly and bunch of articles and tutorials. However I can't figure out how to slice domain to identify bounded contexts which would be microservices.
All what came to my mind is division like I pointed cookbook, planner, ingredient catalog, shopping list but I'm not sure if it's good start for models designing in my app. I'm newbie and I would like to have some advices or ideas from someone who is into designing such things.
I'm designing meal planner app.
As for architecture I want it to be microservices based app.
Services tend to be focused on do-ing rather than be-ing. Publishing a cookbook is one workflow, meal planning is another workflow, and so on.
An important idea in services is that they should be autonomous. There are a number of different ways to understand autonomy, but the one I find helpful is to consider that we copy data from producers to consumers so that the consumers can continue to do useful work even when the producer is unavailable.
For your example, meal planning needs a copy of a published cookbook. But it doesn't necessarily need today's cookbook -- a copy of yesterday's cookbook could be fine. We could achieve this if we had some asynchronous messaging that carries copies of the information from one service to another.
However I can't figure out how to slice domain to identify bounded contexts which would be microservices.
Right - that the hard part, especially when you don't have enough experience in the domain to know what the different processes are, which live data they share, which stale data they share, and so on.
The good news is that if you don't already know the answers to that, it's probably because the volume of information you need to handle right now is small enough that you can do it all together. In other words, first focus on deploying your domain model in a monolith, and iterate on the boundaries of the autonomous modules within it - paying special attention to which processes need to share live copies of the same data, and which processes can use stale copies of data.
Design your persistence model so that features never need to look in somebody else's table (information is copied, not shared). Make sure that the communication between modules satisfies location transparency, so that moving a component somewhere else doesn't break the world.
I'm implementing a college system, and I'm trying to use DDD. I'm also reading the blue book. The basics entities of the system are Institution, Courses, Professors and Students. This system will allow a lot of Institutions, each having its courses, students and professors.
Reading about aggregates, all entities fits inside the aggregate Institution, because doesn't exists courses without Institution, the same for students and professors. Am I right thinking in that way?
In some place the professors will access the courses that they teach. Using this approach, should I always access the courses through Institution? This implementation seems strange to me, so I ask myself if Professor, as Students should be their own AR and have their Repository.
Even though you have accepted an answer I am adding this anyway since a comment is too short.
This whole aggregate root business trips up just about everyone when starting out with DDD. I know, since I have been there myself :)
As mentioned, a domain expert may be helpful in some cases but keep in mind that ownership does not imply containment. An Order typically belongs to a Customer but the Customer is not the AR for an Order since an Order can exist without a Customer. You may think: "But wait, that isn't really true!". This is where is comes down to rules. When I walk into a clothing store I can purchase a pair of shoes. I am a customer but they have no record of me other than a receipt I can produce. I am a cash customer. Perhaps my particular brand of shoe is not in stock but I can still order it. They will contact me once it arrives and that will probably be that and I'll in all likelihood still not be registered in any computer system. However, that same store is registered as a Customer with their supplier.
So why this long-winded story? Well, if it is possible to have an Entity stand alone with only a Value Object representing the owner then it is probably going to be an AR. I can include some basic customer information in a CustomerDetails value object in an Order? So the Order can be an AR.
No let's take a look at an OrderLine. Can I include some basic OrderDetails information on an OrderLine? This feels odd since a number of order lines constitute an Order. So it isn't quite as natural.
In the same way a GrapeBunch has to have a GrapeStem and a collection of GrapeBerry objects.
This seems to imply that if anything can be regarded as optional it may indicate that the related instance is an AR. If, however, a related instance is required then it is part of the AR.
These ideas are very broad but may serve as guidelines to consider your structure.
One more thing to remember is that an AR should not be instanced in another AR. Rather use the Id or a Value Object representing the relationship.
I think you're missing some transactional analysis - what typically changes together as part of the same business transaction, and how frequently ? One big aggregate is not necessarily a problem if only 2 users collaborate on it with only a few changes per day, but with dozens of concurrent modifications it could become a contention point.
Besides the data inventory and data structuration aspect of the problem, you want to have an idea of how the system will be used to make educated aggregate design decisions.
Something that might help you to separate those entities into different aggregate roots is to ask you: Which one of those must be used together? This is usually helpful as a first coarse filter.
So, for example, to add a student to a course, you don't need the Institution?
In your example about a professor accessing the courses he teaches. Can he access them by providing his professor id rather than the professor entity? I he provides the professor id, then the entities won't be associated by a reference but by an id.
Lots of this concepts have evolved a lot since the blue book was written 12 years ago. Even though the blue book is a really good book, I suggest you to also read the red book (Implementing Domain-Driven Design by Vaughn Vernon). This book has a more practical approach to DDD and shows more modern approaches, such as CQRS and Event Sourcing.
A professor and a student can exist in their own right, indeed they may associate themselves with institutions. An institution exists in its own right. A course may exist in its own right (what if the same course is offered at more that one institution, are they the same?)... The domain expert would best advise on that (infact they should advise and guide the entire design).
If you make an aggregate too big you will run in to concurrency issues that can avoided if you find the right model.
Some PDFs I recommend reading are here:
http://dddcommunity.org/library/vernon_2011/
I'm struggling with some implementation details when looking at the terms mentioned in the title above.
Can someone tell me whether my interpretation is right?
For reference I look at a CRM Domain
As a AggregateRoot I could see a Customer.
It may have Entities like Address which contains street, postal code and so on.
Now there is something like Contact and Activity this should be at least aggregates. Right? Now if the Contacts and Activities would have complex business logic. For example, "Every time a contact of the type order is created, the order workflow should be started"
Would then Contact need to be an Aggregate root? What may be implementation implications that could result from this?
Further more when looking and Event Sourcing, Would each Aggregate have its own Stream? In this scenario A Customer could have thousands of activities.
It would be great if someone could guide em in which part my understanding is right and which I differ form the common interpretation.
What do you mean by “at least aggregates”?
An aggregate is a set of one or more connected entities. The aggregate can only be accessed from its root entity, also called the aggregate root. The aggregate defines the transactional boundaries for the entities which must be preserved at all time. Jimmy Bogard has a good explanation of aggregates here.
When using event sourcing each aggregate should have its own stream. The stream is used to construct the aggregates and there is no reason to let several aggregates use the same stream.
You should try to keep your aggregates small. If you expect your customer object to have thousands of activities then you should look at if it is possible to design the activities as a separate aggregate, just as long as its boundaries ensures that you do not leave the system in an invalid state.
My domain consists of Products, Departments, Classes, Manufacturers, DailySales, HourlySales.
I have a ProductRepository which facilitates storing/retrieving products from storage.
I have a DepartmentAndClass repository which facilitates storing/retrieving of departments and classes, as well as adding and removing products from those departments and classes.
I also have a DailySales repository which I use to retrieve statistics about daily sales from multiple groupings. ie..
DailySales.GetSalesByDepartment(dateTime)
DailySales.GetSalesByClass(dateTime)
DailySales.GetSalesByHour(dateTime)
Is it correct to have these sales tracking methods in their own repository like this? Am I on the right track?
Since domains are so dependent on context some answers are harder than others. I would, however, place statistics on the Query side of things. You probably do not want to be calculating those stats on the fly as you will be placing some heavy processing on your database. Typically the stats should be denormalized for quick access where only filtering is required.
You may want to take a look at CQRS if you haven't done so.
Although most queries return an object or a collection of objects, it also fits within the concept to return some types of summary calculations, such as an object count, or a sum of a numerical attribute that was intended by the model to be tallied.
Eric Evans - Domain-Driven Design
This might be considered a read model. Are these daily sales objects being used in any domain model behaviour? Does any business logic depend on them? If not, it might be a good idea to separate this out into a distinct read model - at which point you're taking your first steps into CQRS.
I am trying to study some aspects of ddd with the domain of a car rental website.
The user/customer selects a car from a start and destination station and the time period.
The price calculation depends on various things like payment method, time, car classification and so on. The data is retrieved from a subsystem which differs in data access strategy from the rest of the application.
There are several actors in the domain like station service, call center...
Idea for the bounded context are
Company (employee, car, station)
Booking (reservations, model for booking request process)
Pricing (the price model)
Billing (rental billing, positions, customer)
After defining the bounded context I am unsure if the aggregated roots of each are correct. My thoughts are
Company: all three of them
Booking: reservation (access to billings, the car and customer)
Pricing: tariff matrix
Billing: customer (access to reservations, billings)
If needed I can add some class diagrams to show the different bounded context.
If more information is needed, a class diagram or this should be migrated to an other section feel free to ask/do it.
With what little experience I have with the car rental domain, I'd say you are on the right track. A couple of things you should be aware of: Bounded Context are a logical separation, not a physical one. As such, using something like a compositional UI, would allow you to display pricing information as part of the booking process. You'd be hosting UI components from different BCs side by side, and using them to guide the end user through the process he's trying to complete. The other thing is, you're looking for aggregate roots in all of the BCs, but I do hope you realize that you don't need a domain model in each and every one of them. Maybe a simple datamodel will do if things are not "core" to your business or crud-based by nature. That's the beauty of BCs, the ability to make deliberate technology choices.