I am trying to learn domain modeling , now lets consider a shopping cart example.Lets user can browse catalog of products and add products to shopping cart, purchase those products.To purchase products he will place order.User can trace his order details.He can call up customer rep to know about status of his order.
Please validate my Domain model in full scope.
Below is Domain Model i have designed , i am having issues in representing order and order status what is the right way to do
How would i link product and order.
A (conceptual) domain model is a solution-independent description of a problem domain produced in the analysis phase of a software engineering project. It may consist of information models (typically in the form of UML class diagrams), process models (typically in the form of BPMN diagrams), and possibly other types of models.
A domain class model contains only conceptual elements, such as properties (possibly without datatypes) and associations. It does not specify the visibility of properties and methods, as visibility is a platform-specific concept.
Your model is incomplete in many respects (e.g. it does not describe order lines/details, which are taken from the cart), and it does not contain any association. Clearly, an order is associated to one customer and to many items/products (via its order lines).
OrderStatus should be modeled as an enumeration, which is a UML datatype that is stereotyped with <>, and Order should have a status attribute with this enumeration as its range.
The model below may be a bit more general than what you had in mind, because it allows for several warehouses from which an order item can be sourced, and it also distinguishes between private and corporate customers.
You can make "order details" an associative class for the relationship between order and product. See the example:
IBM example of an associative class
Note that yours is really a class diagram. A domain diagram shows the dependencies on different problem domains such as
Order fullfillment
Database
RemoteCommunications
SystemMaintenance
etc.
Related
I am implementing a multi-company project and noticed that several models in the payroll modules are missing the company_id field.
Is there any official documentation explaining what would be the behavior of Odoo's multi-company environment
when company_id is not defined in a model?
I made some tests...
When I created records from these models, I noticed two different behavior.
On one occasion the record was shared between companies (as if there were a company_id field set to false).
On another case, the record is not visible outside the company from where I created it.
Thanks
I am new to openerp I came across res.partner but I couldn't understand what it does and what all functionalities it provides,so if anyone could explain it to me I would be grateful.
To clarify.
res.partner is an ORM Model. An ORM model describes a class of objects in the database and provides a series of ORM methods to allow you to manage them in code (create, write, unlink etc).
To get the database table, unless there is a specific _table override, just convert the periods to underscores so the table in the database is res_partner. As with any "res." model, you get res.partner as part of the core of OpenERP rather than any additional model such as accounting or sales.
But to answer a wider question, what is res.partner for in OpenERP? Assuming OpenERP 7, res.partner contains information about any entities you have a relationship with.
This includes:
Customers - you have a res.partner entry for each customer plus a res.partner entry for each contact person or address (invoice to, deliver to) you set up for that customer.
Suppliers - same as customers. In fact, the only difference between the two is a boolean field on res.partner to say if they are a customer or supplier.
Users - each user allowed to log in to your OpenERP instance has a related res.partner to store address details.
Companies - each company you set up in OpenERP assuming you are using multi-company has a related res.parter to store address details.
res.partner is the technical name for the Model representing Partners:
Partners represent People and Organizations.
The most straightforward example are Customers and Suppliers.
Other examples of Partners are:
Contact persons within an organization
Customer or Supplier Adresses
Employees personal contact data
Users contact data
So it's a base concept used pretty much everywhere in the application.
Two resources:
/user
/product
The database table name is user_product and it describes relation between user and product. However, endpoint POST /user/{id}/product/{id} would indicate updating a specific product under user, as opposed to creating a new relation.
I have therefore named the resource POST /user/{id}/product/{id}/purchase, which defines fictional resource purchase. After all, this is what the data in the table represents.
I am aware that the original dissertation describing REST principles does little to standardise naming. I'd like to know what are industry established conventions for naming resource that identifies a relationship between two resources?
I would guess that your purchase is stored in a database somewhere and the actual purchase assigned its own ID. Why not use that ID directly as in /purchases/{purchase-id}?
Your example /user/{id}/product/{id}/purchase won't work if one user has more than one purchase of the same product. Unless of course the resource either signals "The user has at least one purchase of product X" or returns a list of all purchases of product X for that user - which looks more like a query (which is fine to assign its own resource).
I have therefore named the resource POST /user/{id}/product/{id}/purchase.
Please be aware that you don't include method names (like POST) in resource names. And why the POST? Is it for creating/modifying the relation - or did you mean GET to get some information about the relation?
I am aware that the original dissertation describing REST principles does little to standardise naming. I'd like to know what are industry established conventions for naming resource that identifies a relationship between two resources?
No, but if you want some hints then I wrote a piece on this subject here: http://soabits.blogspot.dk/2013/10/url-structures-and-hyper-media-for-web.html
We have an app which is exposing a RESTful API to a UI for purchasing an item. I have a question regarding API design. Lets say the following action should be taken in order
Item to be chosen for purchase
Next give the address to be delivered to
My question is: should we design a single API which gets both data perform both? Or should we design two API calls - one that creates a purchase record and second that update the address to be delivered to?
The recommended SOA approach is to choose coarse-grained services, which would seem to argue the minimum amount of API calls.
However, from a business point of view, item selection and purchase and item delivery are two very different concerns that should be separate components in your architecture. For item selection, you need to consider things like inventory and pricing. For delivery address, you need to consider user address lists, address validation, shipping, and taxation.
Those two components are not likely to interact much except maybe some external association between an item id and address id. For this reason, I'd recommend two API calls. Functionally, this would also allow your API users do things like update the delivery address without re-purchasing an item, send the bill to one address and the item to another address, etc.
As you state that you design a RESTful API you usually start by designing resources instead of the intended calls. Later on, resource representations can be chosen that include other resources for optimised HTTP request counts.
You might want to choose to proceed the following way:
Model the item list resource (GET - lists all items, POST - allows item creation) /items/
Model the address list resource /addresses/
Model the item instance resource /items/item/resourceId
Model the address instance resource /addresses/address/resourceId
Now all of your resources are available you can think about usage patterns. All your resources are generically available and can be mashed up.
Possible approaches to answer your questions would be:
Extend the item instance resource with the needed address details (coarse grained as lreeder stated)
Model a resource /deliverydetails/ as list and instance resource containing item(s) and address, make the deliverydetails to be queried by item id or whatever your use case fits best
Hope that helps!
Btw. you are automatically following SOA approaches with a Resource Oriented Design. Interfaces will be naturally fitting your business requirements and generic enough to support more advanced use cases.
Here is a good example
I am new to this, so my understanding is still flaky.
I have a Person model and an AccountType model in my project. Each person references an account type.
Now if my understanding is correct a Person is definitely an aggregate root, whereas the AccountType probably isn't as the entries in the account type table are going to be pretty much static and are certainly have no meaning outside of a Person.
However when I create a new person I need to set the account type, so it would seem I need a repository to access the account type to assign to the user, but the repository code I have only allows aggregate roots to be accessed.
What would be the correct way to structure this?
I think that AccountType is another aggregate root which is referenced from the Person aggregate root.
It's absolutely normal to have many simple aggregate roots, see Vaughn Vernon articles, see part 1, p. 5:
On one project for the financial derivatives sector using
[Qi4j], Niclas [Hedhman] reported that his team was able to
design approximately 70% of all aggregates with just a
root entity containing some value-typed properties. The remaining 30% had just two to three total entities. This doesn't indicate that all domain models will have a 70/30 split. It
does indicate that a high percentage of aggregates can be
limited to a single entity, the root.
In your question it's not quite understood, what is the problem with accessing repositories to initialize the aggregate root's properties:
However when I create a new person I need to set the account type, so it would seem I need a repository to access the account type to assign to the user, but the repository code I have only allows aggregate roots to be accessed.
The initialization of the Person class should be handled by PersonFactory.
The PersonFactory is a service, so it can have reference to AccountTypeRepository to find a suitable AccountType instance and return a fully constructed Person instance of that type.
update: Also I'd like to add a note that referencing your AccountType by id works equally well. It's all matter of convenience, sometimes it's more convenient(only for displaying, not for modifying, of course) to access the references directly if you use GUI frameworks with rich data binding capabilities like WPF or Spring MVC so you can directly access this properties to display in View. If you are using the id approach, this may force you to create ViewModels (FormBeans) even for the simple Entities.
Regarding the lookup-based solution, it works well for very simple enum-like fields, I suppose that AccountType is something more complex than that and belongs to the knowledge level (see the discussion of the question).
Returning to the choice between aggregates and value object(also see this), it depends on the abstraction level and configuration capabilities of your information system.
From the point of view of the Account class it may look like a value object, you can replace one AccountType with another: it will be just like switching between Color value objects, but from the point of the knowledge level your user may want to customize the behavior of the system for selected AccountType, for example change discounts for specific "Premium" accounts. So if you have the knowledge level, AccountType will be something with an identity which leads you to creating a separate repository.
The most important thing is (assuming AccountType has an entity with an ID and is not a simple enum)...
Account Type and Person should only reference each other by ID.