Suppose I have a User entity. And this entity must have a Country field.
As a rule, Country is a Value Object.
And here it's kind of okay, and there's no problem.
But I got a ticket, which says that now on Frontend, Country must be filled in from the list of available Country (also I need to expand this list in the future)
This would be an easy task if Country was originally an entity, but I have it as a Value Object.
What to do in this case? Redefine Country as an entity, or is there another way?
Even when you maintain Countries as entities, you can store them as part of the User entity as a Value Object. The fundamental nature of a country object is such that its value is its identity, making it a good candidate for a Value object.
But IMHO, the list of Countries can be preserved as a static list because the list is finite.
I don't know what it means for your app to add a country to the list, but I am assuming that it is not as trivial as a CRUD op. If the list is rarely updated, you can maintain the list of available countries as a static list in code that is updated when necessary.
If the requirement is to often switch a country from available to not-available and vice-versa, you can store them as CRUD entities but use them as Value Objects in User.
Related
I have just started to look into DDD, and is trying to look into some scenarios.
I have a Product (Entity) with a ProductName (Value Object) and a ProductPrice (Value Object). The Product Price then have an amount (decimal) and a Currency.
My issue is regarding the Currency. First I designed this as a Value Object, but it should be possible to add new Currencies to the system, and it should also be possible to list them in some kind of GUI. In other words it seems like I need a repository for Currencies. In my mind this means that Currency should be designed as an Entity.
But, now I have a Value Object (Product Price) referencing an entity (Currency). How should this be handled? My guess (I am not sure) is that I remove the reference to the currency entity inside the Product Price, and instead adds the Id of the Currency (USD, EUR etc). The Currency then becomes its own aggregate.
Is this a valid and preferred design in DDD, or should this be done in some other way?
In the original DDD book, Evans did discuss the possibility of having values that can reference entities. (Chapter 5: "VALUE OBJECTS can even reference ENTITIES")
I think everybody, by and large, has abandoned that practice. Immutability is too powerful an idea. Values will normally only reference other values. Instead of referencing a entity, we include the entity identifier.
So the usual solution would be that you model the currency code as a value, and store (copies of) that value in your Price value.
The Currency then becomes its own aggregate.
I would not expect this to happen. How does a currency change over time?
What I think you will find is that currency is fairly static: the thing that changes over time is the CurrencyExchange -- which currencies are currently listed? what is the exchange rate today? What was the exchange rate two years ago? Which political units prefer this currency as of Thursday?
Currencies are closer in nature to units of measure: feet, inches, meters, pounds, liters seconds. Meters are a unit of measure in the dimension of length; currency is a unit of measure in the dimension of "money".
how do you handle that new currencies can be added to the system, and how can you select between currencies in the GUI?
There are two possible answers to that.
If your domain is the authority for which currencies are active in the system, then the currency registry/currency exchange should be a first class entity in your domain model, and manages the process of change to the listed currencies.
If your domain is not the authority, then you just cache a copy of the information you get from the authority. Caches are typically CRUD (PUT, GET, DELETE, maybe PATCH).
I have a list of 18,000 unique entities in SAS. In most cases, individual entities refer back to a broader general entity, but differ in spelling. For example, "BANK OF MADEUPBANK" and "BK OF MADEUPBANK" would exist in the list as unique entities even though they are in fact the same entity. My goal is to group the entities that are actually the same by a generic customer name. For example, the generic name "BANK OF MADEUPBANK" would apply to "BK OF MADEUPBANK", "BANK OF MADEUP", "BK OF MAD UP", etc. This is straightforward to achieve programatically with various string searches for some common, large entities. However, there's no way to apply a string search for obscure entities that I wouldn't even know are in the list without reading through all 18,000. I'm wondering if there is a way to conduct the logical process I used on this made up bank to catch all related instances within the list of 18,000...but without knowing what the ultimate general entity is. Is there a technique that can scroll through the list of names and group them based on similarity?
Thanks!
I have two forms that are related and I would to combine them in a view control. Not that difficult. This is for a "1 to Many" type scenario.
Say I have a customer view with the columns customerID and Customer Name. Then I have a view showing the "many" documents that has the columns masterCustomerID, orderNumber, orderDate.
On the XPage I create a view control of the many documents and add the columns masterCustomerID, orderNumber, orderDate. Then I add a column in the front to do a DbLookup to pull in the actual name of the customer. Nothing too fancy really.
My question is, in this situation, where the lookup column is the FIRST column. What are the strategies to sort the view column by that column. By default it would sort by the Key Value in the order view which is likely different then the Name values.
I'm not averse to using repeat controls if that would be easier.
My first thought would be to employ TreeMaps somehow, but I don't know if that's practical in the event that there might be a LOT of documents. Maybe there's something I'm missing...
Any advice would be appreciated. Thanks
Use view with (Customer name, Customer ID) structure as main view. Then based on Customer ID populate other columns by lookup from view with structure (Customer ID, Order ID, Order date). Hence it is 1:N relationship, you can't use single view component, but two nested - repeat inside view column would do.
I hope you are aware of performance impact (orders looked up for every customer row), so don't try to show too many customers at once.
I have Person class which is root of its aggregate, this aggregate also contains country and state province as vo.
{Person, Country, StateProvince} - > Person is root aggregate.
//
Public Person(string name, string country, state province,{other params}){}
// But now i am facing problem in UI, how will i populate Dropdown for Country and Stateprovince, through person because it is root aggregate, but i don't want any person's assigned Country or Stateprovince but i want list of all countries and their Stateprovince, so that user choose one from them
Do i manually create table for country and stateprovince and fill them with all values manually.If yes, then how will i get values from those tables in ddd .
Your model is trying to tell you something.
Country and StateProvince are probably not part of the Person Aggregate.
Remember the very handy "delete test" for an aggregate, ask if I delete this person do I also delete their country and StateProvince? I live in Canada, and you remove me from your system are you also going to delete the country Canada from your system as well?
No, you would not. You have two separate aggregates here Person and Location which would contain the Aggregate of {Country, StateProvince} If you delete a country you would very likely also delete all the states or provinces contained within it as well.
Just because Person references a class or has-a class doesn't make all the references part of that aggregate. Location is very common aggregate in many systems and regularly stands on it's own.
You should have a Person Repository that utilizes a LocationRepository and have the UI directly call the LocationRepository to obtain Location Aggregates.
You would populate your country and state province from different tables. You would then fill the drop downs from these tables. When working with a specific Person entity which has already got Country and StateProvince assigned you would bind them with master tables through id.
Hope that helps.
SharePoint Lookup field, what is it?
Please share, thanks.
It is a type of field used to indicate that the possible values of a column in a list must be taken from the elements of another list. For example, if you have a list of users, and one column of this list is the country, you can create a lookup field pointing to another list "countries" which contains the possible values to select.
If you think in terms of relational databases, a lookup field is a foreign key: you only store a reference to the related item, not its value.
For instance, you have a list of meeting rooms. You can create a meeting calendar by creating a new calendar list with a lookup to the "Meeting rooms" list. Hence, when organizing a meeting, you will be able to pick a room from the list of meeting rooms entered previously.
A "Lookup" differs from "Choice" field as you may alter the source item and the referencing item is updated automatically. For instance, you change the name of a meeting room - all meetings booked for that room will show the new title automatically.