I have above class diagram. I am very confused on whether the above product methods should place in Product class or the user class. If I am right in my diagram, so I should only place product's setters and getters method on it?
Yes, your approach with placing the addProduct, deleteProduct etc on NormalUser is correct.
You might still have for example edit operation on Product to handle calls from (for example) NormalUser depending on your functionality/project/design/... .
Also don't use getters and setters (or at least make them private) unless you really know what you're doing. Providing public accessors to all attributes works in (almost) exactly the same way as making all attributes public effectively breaking the principle of hermetization/encapsulation.
Related
Can we have public setters for the member variables in events/messages created and used through in Axon Framework?
As per my knowledge, events are something that have happened in the past, making them conceptually immutable. Hence, we should not have public setter.
Can someone please confirm this for me?
As you stated correctly, Events are "things from the past" which means they already happened and you should keep them and their contents immutable.
Since they are Java classes, you can create setters but on an Event Sourcing perspective you shouldn't.
I'm currently working on a UML class diagram for an application which is supposed to be like 'Duolingo'.
I am struggling on how to model a many to many relationship.
So, I imagine that you have many users which can take many courses (different languages that they wish to learn). For this reason I have decided to create a courseProgress class to model this many to many relationship.
What I was wondering is, do I need to store the userID and courseID in my courseProgress class? I think I'm getting mixed up here with how keys may be used in a database.
See below diagram:
Am I along the right tracks?
Also, I was wondering when exactly you would use private and public fields. Because to me it seems that you would always want all fields to be private and just use getters and setters to always access these fields?
N.B in the above diagram the fields are public as I have not yet changed them to private
In the diagram above, should I have the userID field and courseID field or should I have a user field of type User and course field of type Course?
You are indeed on the right track. The additional class CourseProgress helps you to better represent the many-to-many association between User and Course. An alternative could have been the use of an association class.
The choice between public, protected or private properties depends on your class design and how you want to expose this information in the object model. This is far too broad to be explained here. To simplify, if the properties are data that could be changed by other objects without any consequence, then you could let it public. If however some properties can only be changed according to some rules with pre-conditions, invariants or post-conditions to be guaranteed, you'd better control the change via a method and thus make the property proteted or private.
Whether or not to indicate the identifiers of the associated classes (i.e. courseId, UserId) depend on the purpose of your diagram.
Typically, for a domain model or a design model, you wouldn't add the properties for representing the classes you are associated with. This is an implementation detail of the association. Usually, you'd rather use the association end to indicate how the instance of the related class would be called.
For an implementation model (example for one-to-many or many-to-many), you may want to show this detail to allow an unambiguous mapping with database tables.
I am working on an online web store. It's a simple web store and I have to create domain UML diagrams for the class and show multiplicities. I am kind of confused about the multiplicity that I have came up with. I don't know how to distinguish between composition, aggregation and association. Below is the diagram that I have came up with. Can someone tell me if I am on the right track?
http://i.imgur.com/8FwhsaI.jpg
Not too bad. You should not bother to much with aggregation unless you need to deal with memory management or foreign key constraints in database design. Just leave them away.
One important change you should make are the role names for associations. E.g. instead of shippingAddress:Address declared as attribute use a role shippingAddress appearing near association on Address that comes from User (etc. for the other ones).
Since Address is sort of a common-place and used all over, you could leave the class out of this diagram and make a separate diagram where Address is in the middle and all others using it surround it.
I agree with Thomas, but I will show other points so can you adjust your diagram.
Please don't see as something destructive. I just believe these tips can help you.
show multiplicities of every connection
do not use getter and setter *
do not use ID's attributes *
Order makes composition with User (does not make sense have an order with a user related with it and OrderLine makes composition with Order;
Product make aggregation with OrderLine and Review make composition with Product;
Manufacturer makes aggregation with Product. ( depend on your system, it can be a composition, but it more likely to be an aggregation).
Remember (the part) makes something with (the whole)
it does not need to create an attribute in a class if you have a connection with that class, except when you have a list of it,( e.g.1: attribute CreditPayment in Payment and Class CreditPayment );
You could make a List of Product in Order. After this, you could delete the Orderline Class.
*if you will not generate a code from the model.
Well I am trying to apply domain driven design principles for my application, with a rich domain model that contains both data fields and business logic. I've read many DDD books, but it seems that their domain models(called entities) are very simple. It becomes a problem when I have a domain model with 10-15 data fields, such as the one below:
class Job extends DomainModel{
protected int id;
protected User employer;
protected string position;
protected string industry;
protected string requirements;
protected string responsibilities;
protected string benefits;
protected int vacancy;
protected Money salary;
protected DateTime datePosted;
protected DateTime dateStarting;
protected Interval duration;
protected String status;
protected float rating;
//business logic below
}
As you see, this domain model contains a lot of data fields, and all of them are important and cannot be stripped away. I know that a good rich domain model should not contain setter methods, but rather pass its data to constructor, and mutate states using business logic. However, for the above domain model, I cannot pass everything to the constructor, as it will lead to 15+ parameters in constructor method. A method should not contain more than 6-7 parameters, dont you think?
So what can I do to deal with a domain model with a lot of data fields? Should I try to decompose it? If so, how? Or maybe, I should just use a Builder class or reflection to initialize its properties upon instantiation so I wont pollute the constructor with so many arguments? Can anyone give some advice? Thanks.
What you've missed is the concept of a Value Object. Value objects are small, immutable objects with meaning in the respective domain.
I don't know the specifics of your domain, but looking at your Job entity, there could be a value object JobDescription that looks like this:
class JobDescription {
public JobDescription(string position, string requirements, string responsibilities) {
Position = position;
Requirements = requirements;
Responsibilities = responsibilities;
}
public string Position {get;}
public string Requirements {get;}
public string Responsibilities {get;}
}
This is C# code, but I think the idea should be clear regardless of the language you are using.
The basic idea is to group values in a way that makes sense in the respective domain. This means of course that value objects can also contain other value objects.
You should also ensure that value objects are compared by value instead of by reference, e.g. by implementing IEquatable<T> in C#.
If you refactor your code with this approach, you will get fewer fields on your entity, so using constructor injection (which is highly recommended) becomes feasible again.
Further notes regarding your example code that are not directly connected to the question:
The domain model is the whole thing, an entity is part of it. So your base class should be called Entity and not DomainModel.
You should make the fields of your class private and provide protected accessors where required to maintain encapsulation.
There's an awful lot going on in your Job domain model object - it seems to mix a huge number of concerns, and (to me at least) suggests a number of bounded contexts, some of which are easy to discern for the sake of making an example.
Remuneration (pay, benefits)
Organisational position (reporting line)
Person spec (skills)
Job specification (responsibilities)
etc.
When you consider the things that interact with your 'Job' model, are there any that need to inspect or mutate BOTH the Salary property and the Industry property, for example?
Without knowing the full nuances of the domain, the Salary you get for holding a position and the Industry you work in are not really connected, are they? Not a rhetorical point; these are the questions you NEED to ask the domain experts.
If they DON'T have any interaction then you have identified that these two things exist in two different BOUNDED CONTEXTS. The Salary side has no need of any interaction with the Industry side and vice versa, and even if they did, do they need to be held as state in the same process at the same time?
Think about the lifecycle of how a person becomes an employee; a person applies for a job. The job has a specification, salary range. The person attends an interview. The hirers offer the person the position. The person accepts. The person is now an employee, not a candidate any longer. The new employee is now accruing holiday and benefits and has a start date etc.
DDD teaches us that a single, unified view of the world rarely serves ANY of the concerns correctly. Please explore BOUNDED CONTEXTS - your software will be much more pliable and flexible as a result.
I am trying to get my hands dirty learning DDD (by developing a sample eCommerce site with entities like Order, OrderLines, Product, Categories etc).
From what I could perceive about Aggregate Root concept I thought Order class should be an aggregate root for OrderLine.
Things went fine so far, however I am confused when it define a create order flow from UI.
When I want to add an order line to my order object, how should I get/create an instance of an OrderLine object:
Should I hardcode the new OrderLine() statement in my UI/Service class
Should I define a method with parameters like productID, quantity etc in Order class?
Also, what if I want to remove the hardcoded instantiations from the UI or the Order class using a DI. What would be the best approach for this?
From what I could perceive about
Aggregate Root concept I thought Order
class should be an aggreagrte root for
OrderLine.
Yes, OrderLine's should most likely be under an Order root, since OrderLine's likely make no sense outside of a parent Order.
Should I hardcode the new OrderLine()
statement in my UI/Service class
Probably not, though this is how it happens often and it is made to work. The problem, as I see it, is that object construction often happens in different contexts, and the validation constraints differ depending on that context.
Should I define a method with
parameters like productID,quantity etc
in Order class?
As in:
public OrderLine AddOrderLine(Product product, int Quantity ... )
This is one way to do it. Notice I used a Product class instead of a ProductId. Sometimes one is preferable to the other. I find I use both a lot for various reasons - sometimes I have the ID and there's no good reason to pull the aggregate root, sometimes I need the other root to validate the operation.
Another way I do this is to implement a custom collection for the children.
So I have:
order.OrderLines.Add(product, quantity);
This feels a little more natural or OO, and in particular if an entity root has many child collections it avoids clutter.
order.AddOrderLine(), order.AddXXX(), order.AddYYY(), order.AddZZZ()
versus
order.OrderLines.Add(), order.ZZZs.Add(), order.YYYs.Add()
Also, what if I want to remove the
hardcoded instantiations from the UI
or the Order class using a DI. What
would be the best approach for this?
This would be a textbook case for the Factory pattern. I inject such a Factory into my custom collections to support instantiation in those Add() methods.
You could use an OrderLine Factory to get instances of Orderlines. You would "new up" an OrderLine object in the factory with parameters passed into the factory method and then return the new instance to your Order object. Always try to isolate instantiations and dont do it in the UI. There is a question here that uses this technique.
Here is a great book you will find useful on DDD.