I am weak in programming and may be that is why I am confused. And I am sorry if this question is off topic. The diagram shows how the table reservation will be made in restaurant. The boundary object is omitted in this diagram. The restaurant object has the responsibility of maintaining the complete set of reservation made for the restaurant. And it will create a new reservation object. It assumed that the data passed from the user contains textual identifiers for these objects, such as a table number and the name and phone number of a customer. This data would be entered by the user when specifying the details of the new reservation. Before the reservation can be created, however, we need to locate the objects identified by this data so that the appropriate object references are available when the new reservation is created. Each reservation object is linked to exactly one table and exactly one customer object? What I don’t understand is that it is really necessary to do like this in a very confused way. It is not enough with just database? There will be reservation table. Whenever user enter a new reservation, the table no and customer information will be entered in that reservation table. Why we need to know the objects?
Because without knowledge of table and customer a reservation can not be completed. Of course you can leave out these objects and each time a reservation is made, you enter table number and customer name manually (e.g as strings '13', 'Mr. Miller'). But if you have this as object you can choose from them. So you have 13 table objects for your 13 restaurant tables. And when you make a reservation you see that it might already be occupied (rather than searching for a possibly mis-typed string in other reservations). If you have customer objects you can connect information with that customer like "Steak always rare").
As a general rule
"If any method/notation makes things
harder, do not use it.Use alternatives or even create your own home
made one"
This is a sequence diagram which shows "object" interactions at runtime to fullfill a goal.So there "are" objects not "classes": dynamic behaviour not static structure.
Be carefull
Do not try to draw sequence diagram (or any UML
diagram) for every object interactions.You should have a valid
"reason" for it and apply it for small subset of your problem space which is tricky or hard...
The main assumption is that
UML will help you to investigating hard part of your problem with the
help of visualization.
UML may fail to satisfy this. If this assumption does not valid for you, just FORGET UML. It is not a BIBLE...It is just simple drawing notation for to help us.
Related
I've written a script to make a cafeteria system at college. I need to know whether my diagram is correct, especially the shares of the operations.
The student selects one of the restaurants available in the cafeteria.
The student selects the item you want with the possibility of adding some ingredients to the item and receive the sellers.
The student pays to the seller. The delivery of a request is included, an update to the store at the moment the student is paid.
The seller's issue the invoice to the student and includes an addition to the account of exports and imports of the restaurant.
Administrator for the restaurant When you want to add new item, the sellers are notified of the new item added.
Administrator records attendance and absence of sellers.
Use correct naming for use cases: predicate, subject (, object).
Do not use include/extend as it's simply mistaken for functional decomposition, which is plain wrong.
Synthesize function descriptions to extract the added value hidden behind those descriptions and make them use cases (single added values the system under consideration delivers to its actors).
It's ok to indicate primary and secondary actors by using directed associations. However, this in no standard, but a convention and needs to be explained in separate modeling rules.
Your saller should likely be Seller. Note the upper case first char too (also wrong with Student).
With little effort your diagram could have been uncluttered!
I am modeling my entities, and have been struggling with this for a long time. Here is my Person Entity:
Person
ID
Name
Email
Password
City
Phone
Biography
Rating
Description
I have tried to divide these properties into Value Objects, but so far I only have been able to convert them to VOs (for example, City is a VO made with a city name, and country name).
Should I try to create larger VOs, by putting together, for example, Email and Password into a Credentials VO ? Am I going too deep in the separation into VOs ?
Any help is greatly appreciated
[EDIT]
After some discussion, it appears that the best solution is to keep every property in it's own VO, except for Email and Password that should be grouped in a "Credentials" VO.
Value objects are things who's values uniquely identify them I.e. equality is done by the values, rather than an explicit property (like ID) to provide uniqueness. Two value objects are equal if all their fields are equal
When trying to identify them, follow the language the domain experts use. What words do they use when discussing People? Do they refer to credentials, or email and password?
Also look to identify groups of properties that are always used together. For example, if Password is always used alongside Email it makes sense to group them in a Credentials object, as you can then push behaviour there (i.e. Credentials.Validate())
[UPDATE]
All of the following properties are candidates for value objects depending on the invariants you need to enforce
Name
are there min / max values for names?
are there any characters not allowed?
Email
is it a valid email address
can two people have the same email address?
Password
min / max length?
required characters?
invalid characters?
Phone
is it a valid phone number?
how do you deal with international dialing codes?
Rating
is there a min and max value allowed for a rating?
how is it calculated? (is it calculated?)
Description
Biography
City
etc....
If you create Value Objects for the above concepts instead of using primitive values such as int or string, you can encapsulate your business rules inside the value objects.
You might want to combine Email and Password into a Credentials Value Object if you use the two things cohesively. i.e. login with credentials etc... You can still access Credentials.Email if you need to use the Email outside of the Credentials object.
What you have there looks suspiciously as a data structure (CRUD). In proper DDD you start with the business case like "Create Person" and then you find out the model representing the Person concept.
The model is defined by a group of components and business rules. Your components are usually VOs , because they are models representing minor concepts that can be expressed as a simple or composite value with no explicit identity and they encapsulate specific business constraints. For example, the Email VO makes sure you have a valid email value.
You should let the domain tells you if it makes sense to create bigger VO; usually you start with a VO and you discover it's made up from other VOs. Generally, we go top to down. You can see here a modelling example.
It's hard when you don't have a domain expert but you can still try to think in business cases and identify whatever specific model for each case. If you end up with mainly simple structures and some data validation rules, perhaps you have a simple enough domain to just use a CRUD approach.
Don't try to impose a particular domain model structure, you need to approach domain modeling from the use cases perspective.
Should I try to create larger VOs, by putting together, for example, Email and Password into a Credentials VO ?
You should do that only if the two tend to be used together. If they don't, leaving them along is just fine.
Note that sometimes it makes sense to extract a single property into its own value object if the number of invariants it needs to support is high enough to justify introducing a new concept. Take a look at this article for more details.
it is not always clear a concept in your domain is a value object or entity and unfortunately there are no objective attributes you could use to get to know it whether or not a notion is a value object fully it depends on the problem domain, a concept can be an entity in one domain model or a value object in another. most of times a money class is a value object but not all money objects are value object. how you can find out a value object? first of all you should check the notion of identity if it is structurally equal (it means two objects are same if objects values are same, not ids of objects), you can safety replace an instance of class which has same set of attributes. that is good sign this concept is a value object.
a good way of thinking value object is thinking if it is an integer, do you really care if integer 5 is same as 5 you used in other function? definitely not all 5 in your application are same, regardless how they were instantiated. that's make integer essentially a value object, now ask your self the object in your domain is like an integer? if answer is yes then it is a value object. also, value objects are immutable and more light weight as entities.
I am trying to get to grips with the ideas behind DDD and apply them to a pet project we have, and I am having some questions that I hope that someone here would be able to answer.
The project is a document management system. The particular problem we have regards two notions that our system handles: That of a Document and that of a DocumentStatus.
A Document has a number of properties (such as title, author, etc). Users can change any of the Document's properties through out its life time.
A Document may be, at any time, be at a particular state such as NEW, UNDER_REVISION, REVISED, APPROVED etc. For each state we need to know who made that change to that state.
We need to be able to query the system based on a document status. An example query would be "Get me all documents that are in the REVISED state".
"Get me all documents whose status has been changed by user X"
The only time that a Document and a DocumentStatus need to be changed in the same transaction is when the Document is created (create the document and at the same time assign it a status of NEW).
For all other times, the UI allows the update of either but not both (i.e. you may change a document's property such as the author, but not its state.) Or you can update its state (from NEW to UNDER_REVISION) but not its properties.
I think we are safe to consider that a Document is an Entity and an Aggregate Root.
We are buffled about what DocumentStatus is. One option is to make it a Value Object part of the Document's aggregate.
The other option is to make it an Entity and be the root of its own aggregate.
We would also liked to mention that we considered CQRS as described in various DDD documents, but we think it is too much of a hassle, especially given the fact that we need to perform queries on the DocumentStatus.
Any pointers or ideas would be welcomed.
Domain
You say you need to be able to see past status changes, so the status history becomes a domain concept. A simple solution would then be the following:
Define a StatusHistory within the Document entity.
The StatusHistory is a list of StatusUpdate value objects.
The first element in the StatusHistory always reflects the current state - make sure you add the initial state as StatusUpdate value object when creating Document entities.
Depending on how much additional logic you need for the status history, consider creating a dedicated value object (or even entity) for the history itself.
Persistence
You don't really say how your persistence layer looks like, but I think creating queries against the first element of the StatusHistory list should be possible with every persistence mechanism. With a map-reduce data store, for example, create a view that is indexed by Document.StatusHistory[0] and use that view to realize the queries you need.
If you were only to record the current status, then that could well be a value object.
Since you're composing more qualifying - if not identifying - data into it, for which you also intend to query, then that sounds to me as if no DocumentStatus is like another, so a value object doesn't make much sense, does it?
It is identified by
the document
the author
the time it occurred
Furthermore, it makes even more sense in the context of the previous DocumentStatus (if you consider more states than just NEW and UNDER_REVISION).
To me, this clearly rules out modeling DocumentStatus as a value object.
In terms of the state as a property of DocumentStatus, and following the notion of everything is an object (currently reading David West's Object Thinking), then that could of course be modeled as a value object.
Follows How to model an entity's current status in DDD.
I´m a little confused about inheritance and relationships in core data, and I was hopping someone could drive to the right path. In my app i have created 3 entities, and none of them have (and are not suppose to have) common properties, but there´s gonna be a save and a load button for all the work that the user does. From my understanding I need to "wrap" all the entities "work" into an object which will be used to save and load, and my question is, do I need to create relationships between the entities? Because I have to relate them somehow and this is what make sense to me. Is my logic correct?
I'm implementing a budget calculator, and for the purpose of everyone understand what my issue is, I´m going to give an practical example and please correct me if my logic is incorrect:
Let´s just say you are a fruit seller, and because of that it´s normal to have a database of clients and also a fruit database with the kinds of fruit you sell. From my understanding I find two entities here:
Client with properties named: name, address, phone, email, etc.
Stock with properties named: name, weight, stock, cost, supplier, etc.
TheBudget with properties named: name, amount, type, cost, delivery, etc.
I didn´t put all the properties because I think you get the point. I mean as you can see, there´s only two properties I could inherit; the rest is different. So, if I was doing a budget for a client, I can have as many clients I want and also the amount of stock, but what about the actual budget?
I´m sorry if my explanation was not very clear, but if it was..what kind of relationships should I be creating? I think Client and TheBudget have a connection. What do you advise me?
That's not entirely correct, but some parts are on the right track. I've broken your question down into three parts: relationships, inheritance and the Managed Object Context to hopefully help you understand each part separately:
Relationships
Relationships are usually used to indicate that one entity can 'belong' to another (i.e. an employee can belong to a company). You can setup multiple one-to-many relationships (i.e. an employee belongs to a company and a boss) and you can setup the inverse relationships (which is better described with the word 'owns' or 'has', such as 'one company has many employees).
There are many even more complicated relationships depending on your needs and a whole set of delete rules that you can tell the system to follow when an entity in a relationship is deleted. When first starting out I found it easiest to stick with one-to-one and one-to-many relationships like I've described above.
Inheritance
Inheritance is best described as a sort of base template that is used for other, more specific entities. You are correct in stating that you could use inheritance as a sort of protocol to define some basic attributes that are common across a number of entities. A good example of this would be having a base class 'Employee' with attributes 'name', 'address' and 'start date'. You could then create other entities that inherit from this Employee entity, such as 'Marketing Rep', 'HR', 'Sales Rep', etc. which all have the common attributes 'name', 'address' and 'start date' without creating those attributes on each individual entity. Then, if you wanted to update your model and add, delete or modify a common attribute, you could do so on the parent entity and all of its children will inherit those changes automatically.
Managed Object Context (i.e. saving)
Now, onto the other part of your question/statement: wrapping all of your entities into an object which will be used to save and load. You do not need to create this object, core data uses the NSManagedObjectContext (MOC for short) specifically for this purpose. The MOC is tasked with keeping track of objects you create, delete and modify. In order to save your changes, you simply call the save: method on your MOC.
If you post your entities and what they do, I might be able to help make suggestions on ways to set it up in core data. You want to do your best to setup as robust a core data model as you can during the initial development process. The OS needs to be able to 'upgrade' the backing store to incorporate any changes you've made between your core data model revisions. If you do a poor job of setting up your core data model initially and release your code that way, it can be very difficult to try and make a complicated model update when the app is in the wild (as you've probably guessed, this is advice born out of painful experience :)
Im new to working with Domain Models so forgive me for asking an elementary question.
If a Domain Object has a 1-many relationship with another Domain Object but logic that uses the first object works with only a subset of that objects related objects, what is the best way to expose this subset?
For example, say a Person is related to many Orders but some external logic needs to examine only the "Dispatched" Orders associated with a Person. Should the Person have a DispatchedOrders property, along with other properties for other subsets (such as CompletedOrders etc) or is this bad design? Assume for performance reasons I cant filter the objects in memory and must use SQL to pull back only the subset I'm interested in.
Thanks
If you're using SQL to find the set you're interested in, you're in a perfect world. Relational queries are all about finding that sort of thing. Find the perfect query, and then just figure out what the class of the result tuples are, i.e., an object for each result tuple, and process them appropriately.
In your example, you want a set of "Dispatched Orders", which whatever person information necessary attached to each one.
I think you have the right idea - DispatchedOrders would tell me precisely what collection of object you are returning to me. As Curt said, you are in good spot as you can use SQL / stored procedure to fetch your data.
One caveat - be sure that the domain matches the business process and is not an interpolation of you understanding of that process. That is - why does a person have primacy over an order and what corner are you painted into when you construct other objects. Does a line-item contain an order as well, and does this lead to object bloat? Discussions with your client should help shape the answer.
Rob Conery of SubSonic fame has a good discussion of these types of issues. It's worth listening to.