I don't see cart model in broad leaf commerce Database model and also in code, order object is used as cart.
I will appreciate if someone from broadleaf commerce help me out to understand that why cart is not there.
Thanks,
Vijay
In Broadleaf, a cart is an Order with a status of IN_PROCESS. We do not think of a cart as separate from a real Order; it just represents an Order that has not yet been submitted.
Javadoc for the various statuses of an Order.
Related
I am trying to use Domain-Driven Design in my project. In the project, a seller can create a Post to sell Items. A seller can include multiple items in a post; each item includes details such as quantity, size, and price. A buyer can buy one or many item of the same post.
I am not sure if Post or Item should be the aggregate. I personally feel that it would be more correct for Item to be the aggregate, but I am not entirely sure.
A book I am reading states: "An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes". Say, post X includes two items, a and b. When a buyer buys item a, we should not lock item b even though it also belongs to Post X, so it makes sense to choose Item to be the aggregate.
However, how about entity Post? If I make Item to be the aggregate, Post would not belong to any aggregate? What would the entrypoint be if a seller wants to create/delete a post or change items in a post? so it kinda makes sense to choose Post to be the aggregate too.
Thank you sooo much in advance for your help!
It seems like Post and Item are each good aggregates.
As a meme on social media asks: "Why not both?"
Note that doing this implies that a Post won't contain Items; instead, a Post will refer to Items by some identifier (which identifier would effectively be a value object).
This also suggests that one shouldn't depend on updates to Posts and Items being mutually consistent: you may need to resort to modeling an explicit process in your domain for disabling/deleting an Item and removing that Item from associated Posts, for instance.
In my system, an User can be member of a Team.
I got a domain model called Team which contains id, name, member_count and is_channel. So when I fetch teams in the repository I retrieve the Team domain model.
How would I model the relation between a User and a Team? Because when talking about the relation I don’t care about the member_count and is_channel from the Team model. I even have extra data in the relation which is a role_type.
Should I create a domain model for the relation called TeamScope or something? That contains id, user_id, team_id, role_type?
See my comments on your question regarding your use of terms (model, class, association). I'm assuming you are misusing them when I wrote my answer.
How would I model the relation between a User and a Team? Because when talking about the relation I don’t care about the member_count and is_channel from the Team model (sic). I even have extra data in the relation which is a role_type.
You could use an association class in your domain model to represent this.
Membership can capture the role_type, which really is linked to the association as you have figured out.
member_count is represented with a / at the start, indicating that you'll derive its value from the multiplicity (it's a count of the number of members associated with the team).
You tagged node.js in your question, so I'm going to point to how to implement association classes in Java (not exactly your case, but in Node.js it should be easy to apply).
You should almost definitely model a TeamMember object which contains both a link to the User, a link to the Team, and the role the user plays on that team.
Teams have a list of TeamMembers, Users have a list of TeamMembers. Teams have a MemberCount (not sure if this is static, or dynamic from the count of TeamMembers), and I have no idea what is_channel means...
I am doing UML class diagram for the first time. I have put a data store in class diagram I am not sure if I can . Also, is it possible to get feedback on this class diagram I have uploaded?
Basically its a hotel management system.
I am explaining the story point wise here. I have removed the unwanted stuffs from the story.
1) Login - Allow user to search room if he is a registered user. If not he/she should be able to register to hotel management system.
2)User should be able to search the available rooms from the system and select a type of room-Available rooms based on check in and check out dates.
3)Hotel employee should be able to charge for the facilities availed.
4)Store user information for marketing Purposes.
5)User should be able to cancel made reservation of rooms.
6)Make payments online.
7)User/receptionist should be able to modify/update rooms booked, User information from the information they have. - I added data store.
Placing login method in the class which gains login does not seem to be reasonable. Authorization should be a class of its own and a user may gain access through it.
There is nothin modeled which shows the occupation of rooms. I'd expect some Occupation class which links rooms to time ranges.
The same. What is the basis for the occupation? There needs to be an Occupation class which relates Room with time frames.
What are marketing purposes? You could implement some user statistics that traces when a user has booked rooms, how punctual he paid, etc. Those are not modeled.
Since you have not modeled a Reservation you will not be able to cancel it.
The Payment is related to nothing. So you don't know for what a payment was made. Your book keeping will love you for that :-(
As above: no reservation modeled - no modification possible.
You should probably find some mentor to sit together and do some basic modeling.
Edit (as on the updated model): This is not the way to go. The datastore will serialize the single objects, and not be a class of its own. The way you need to do it is to construct a model with the relevant classes. Those will finally result in persistent objects in the database. FacilityAvailed does not look sensible. This looks like information you can compute from Reservation (which needs a relation to Room which is now missing completely). Well, you should dump this approach and start all over. Just model the business objects (BO): Room, Reservation, User, Payment, etc. Relate those meaningful. What are the attribute of each BO (Room: Number, Size, Cost,... User:Role, Name, ...). Then try to relate them. E.g. a Reservation may relate Room and User, but could also be simply for refurbishment/cleaning etc.
I have this assignment for school where I have to model a sort of e-commerce site that delivers grocery bags to customers (http://www.linasmatkasse.se/). I haven't received any use case, or anything.
The only directions I've been given is that it's supposed to be a domain model of max 40 classes, of a web based business (like described above).
This is what I have so far.
Are the aggregations decent? (Especially between Customer and Account)
Should OrderStatus & AccountStatus be associated or not?
Is there any use for inheritance here?
Are there any redundancies, or anything that should be added?
Appreciate any feedback! Thanks!
change colors and font size of the picture, please - it is very hard to read.
Aggregations aren't OK. Composition - black diamond means, that item belongs to container and can't exist without it. Of course, an item can't belong to two containers this way. Change to shared one or two compositions. Customer and account CAN be connected so. But better think of Account as of association between Customer and Website.
Connect Cart and Order
Why OrderStatus and AccountStatus should be connected? I don't understand, why they need to be connected directly?
ItemDescription connect to item, or better, to ClassName, not itemlist
Why OrderItemList is connected to WebSite? What is it at all? Why Order is not enough?
What is SalesLineItem? Maybe, it should belond to OrderItemList?
Change ClassName to ItemClass - don't use terms accepted for other things.
Yes, you could use inheritance - Cart and Order should not be independent in this sense. But you'll decide, who is the parent. Or make "cart" one more status of Order. Or use both.
Heaps of things could be added, but obviously, it is not the real task, merely a piece of play. Think way of delivery, way of payment. Show navigability. Show names of arrows, not of connections.
Set attributes and functions.
I'm facing a typical DDD problem. It must be very basic. I have an order and customer.
A customer can create multiple orders. Customer is the root of its own aggregate. Order is the root of its own aggregate. But when a customer creates an order, we display some portion of the customer information on the order. Should Order aggregate hold reference to customer?
When it holds it then when the Order Repository gets the order, we are able to retrieve some portion of customer information as well for display. But when we involve the order in a transaction, customer also gets into it which is creating problem if the customer is also getting updated at the same time. Please advise guys ! My gut feeling says I MUST not hold reference to customer from order.
Question 2: (NEW)
Can I get and hold a reference to the Customer (from Customer Repository) for a given Order while creating an Order (using Order Factory) and safely save the Order (without updating the Customer inside in anyway, Customer is there only for information/query?) without creating contention if the same Customer is getting modified else where? Lets assume NHibernate as ORM.
A simple answer will be that you hold the ID of the customer or, if needed for your domain some ValueObject with a minimal set of information about the customer ( ID, Name ).
A more complex answer is to think about Bounded Context. See Eric Evans's presentation where he wishes he had put the BC chapter as the first chapter in the book.
The idea is that in your Customer Management Bounded Context, your Customer entity can be the AR of the Customer Aggregate and the Orders can be entities in the Customer Aggregate. In the Billing Bounded Context you can have an Order AR with a Customer entity inside.