I have an application in which an Engineer accesses gas wells. He can see a list of wells by choosing any combination of 7 characteristics. The characteristics are company, state, county, basin, branch, field, operator in their respective order. The application starts and I need to retrieve a list of companies. The companies the user sees is based on their security credentials. What would be my aggregate root/domain object which to base my repository. I first thought user, but I never retrieve anything about a user. The combination of those items and a couple of other attributes are collectively called wellheader information. Would that be the aggregate root or domain object for my repository?
Thanks in advance
With a short description like that, it can only be a quess on how your design could be.
As I read it, your are really interested in wells for a given engineer. (is the engineer the user you mention?)
So a first try could be to model the concept of a well as an aggregate root.
So maybe something like this:
ICollection<Well> wells = WellRepository.GetWellsForEngineer(engineerInstance);
Maybe your engineer is associated with a characteristics object.
Either way, you have to associate the engineer with wells in a given company, state and so on to be able to extract which wells the engineer is actualy assigned to.
If this dosen't help you, maybe you could elaborate on your domain.
Related
In my company (train company) there is a sort of battle going on over two viewpoints on something. Before going to deep into the problem I'm first going to explain the different domains we have in our landscape now.
Product: All product master data and their characteristics.
Think their name, their possible list of choices...
Location: All location master data that can be chosen, like stations, stops, etc.
Quote: To get a price for a specific choice of a product with their attributes.
Order: The order domain where you can make a positive order but also a negative one for reimbursements.
Ticket: This is essentially what you get from paying the order. Its the product but in the state that its at, when gotten by the customer.
The problem
Viewpoint PURPLE (I don't want to create bias)
When an order is transformed into all "tickets", we convert the order details, like price, into the ticket model. In order to make Order something we can throw away. Order is seen as something transient. Kind of like the bag you have in a supermarket. Its the goods inside the bag that matter. Not the bag itself.
When a reimburse flow would start. You do not need to go to the order. You would have everything in the Ticket domain. So this means data from order will be duplicated to Ticket.
But not all, only the things that are relevant. Like price for example.
Viewpoint YELLOW (I don't want to create bias)
You do the same as above but you do not store the price in Ticket domain. The ticket domain only consist of details that are relevant for the "ticket" to work. Price is not allowed in there cause its a thing of the order. When a reimburse flow would start, its allowed to go fetch those details from the order. Making order not something you can throw away as its having crucial data inside of it.
The benefit here is that Order is not "polluting" the Ticket with unnecessary data. But this is debatable. The example of the price is a good example.
I wish to know your ideas about these two viewpoints.
There is no "Don't repeat yourself" when it comes to the business domain. The only thing that dictates the business domain is the business requirements. If the requirements state that the ticket should work independent of the order changes, then you have to duplicate things.
But in this case, the requirements are ambiguous. There is no correct design using the currently specified requirements. Building code based on assumptions is the #1 way of getting bad code, since you most likely will have to do a redesign down the road.
You need to go back to the product owner and ask him about the difference between the Order and the Ticket.
For instance:
What should happen to the ticket if the order is deleted?
What happens to the order and/or ticket if the product price changes?
What happens to a ticket if the order is reimbursed?
Go back, get better requirements and then start to design the application.
For my internship, I need to implement a blockchain based solution to manage a drug supply chain. The management of this supply chain implies to track-and-trace (geolocate) a drug on the chain, but also to monitor the storage temperature to see if the cold chain is respected. For that I created a mock-up of the POC my Dapps (https://balsamiq.cloud/sum5oq5/p8lsped)and also I wanted to prepare myself by doing a UML and a use cases. However, I didn't find a lot of information about blockchain's UML and use cases besides two literatures which were quite different, so I don't know if what I did was correct or not...
The users of my Dapps will be the following ones:
The stakeholders (Manufacturers, Distributors and Retailers) which will use the Dapps to place orders and also monitor them. They also can search in the historic a specific order. Finally, trough IOT sensors they update the conditions of the order (temperature & location).
The administrator which roles is to update the Dapps and its rules. But also to add or delete user while also defining the rights that they have on the blockchain (I intend to use a permisionned blockchain). Finally, they are also here to help in case of technical problem.
The Dapps that I'm thinking about works in the following:
A user, the customer, can place an order (a list of products) to a
certain seller and choose the final destination of the order.
The order is then put together before being shipped or stocked in the
depots of one of the stakeholders (distributor or retailer) with a
description of the stocking and/or shipping condition of the product
(for example the product must be stocked or transported in a room
with a temperature of less than 5°C). During the shipping and
storing, an IOT device will feed the drops with the temperature and
geolocation of the product by updating the data each 5-10mn.
Obviously they will be a function that allows all the users to see
the history of the order passed and search inside a specific order.
In case where the temperature doesn't respect the temperature
recommended, then the smart-contract send an alert. The same if the
collocation of the product is "weird" like being in some European
countries and not in an Asian country, an alert will be sent again by
the smart-contractual. Finally, in the case where the product is sent
to the asked location by the customer, then the money for the order
will be paid to the seller.
So based on what I explained, I came here in hope that someone tell me if the use cases and UML that I did were correct or not.
I thank in advance anybody who'll take the time to help me.
I am new to DDD and decided to practice it with a dental clinic system I'm developing, but I'm struggling with modeling the domain so an extra pair of eyes will be greatly appreciated.
For this dentistry system, the domain expert told me that a patient holds only one medical history. The medical history must have a Record Number which is unique on the system. The medical history holds dental treatments the patient could have (like planned treatments) as well as treatments that the patient already had. Every treatment has a price, and so the medical history contains a Total price on it (based on planned/applied treatments). Whenever a patient gets a treatment done, he/she will have to pay with at least 50% of that treatment price, meaning he/she will eventually pay the rest of it on future appointments (if no treatment plan exists, he/she will have to pay for the 100% of the price). Finally, this dentistry clinic gives the option to patients to pay on different currencies, because sometimes a patient that comes for the day has only Euros, but then he decides he wants a plan and for future appointments will pay on Pounds.
Based on all this, and my beginner knowledge of DDD, my first thinking is that I have these entities:
Patient
Treatment
Dentist
I will have several value objects, but the most important ones might be:
Money (for prices and currency)
Signature (for applied treatments)
Tooth or Teeth (used on Treatment entity)
And I can only find one aggregate which is Medical history since it puts together patient info, as well as treatments (planned and applied). But this will mean that whenever I update a Medical History, I will have to update patient info and treatments, even if one of those never changed. Patients could change their personal information, which will be reflected in medical history, but it doesn't affect treatments.
I am a bit confused on how to model this. Please help!
Remember that Aggregates, and by extension Bounded Contexts (BC), are a grouping of data and business logic that belong together (and most likely things that need to change transactionally). The data that an aggregate contains is there because the business logic needs it, not because some application screen needs it. This is very important to clear up some confusion and to free you of some constraints in order to design your aggregates.
For example, when you display the Medical History to the user, you might want to show the Patient's name, address, age and so on, and also the treatments prices, but if you think about it, you don't need any of this to manage the Medical History. From what you say, the Medical History has a Record Number, a PatientId, and a list of TreatmentIds with maybe the Dates when they were done.
When you want to display the Medical History to the user, you can use UI Composition. So, you get the Medical History (which is mostly a bunch of Ids and dates). Then from the Medical History's PatientId, you can get the Patients's information from the BC that owns it. From the TreatmentIds, you can get the Treatment descriptions from some BC that owns that and their prices from the BC they belong to.
So, based on that, you can build your aggregates not based on the "relevant names" on your domain like Patient, Treatment or Dentist, but by the business logic they implement.
This is just wild guessing, but I can think of:
BC Marketing (for lack of a better name): Contains the descriptions of all treatments, information about the Dentists, Information about the rooms and materials, etc. So, texts, pictures and other details.
BC Finances: Contains information about the prices of each treatment, payment records of each payment, credits and debits of each patient, etc. In charge of keeping track of all these things. For example, it could know when a treatment starts/ends and depending on the Patient's record, require 50 or 100% payment. There's no need of direct relation to the Medical History here, it only needs to know if it's the first treatment or not.
BC Scheduling: In charge of scheduling new treatments and keep track of when they start and finish. This could contain the History, or it could potentially be somewhere else if necessary.
BC Medical: In charge of keeping all the medical records, allergies, medical details of the status of the teeth, etc.
BC Patients Care: In charge of tracking patients' information, name, nationality, contact details, etc.
Once you have an idea of the Bounded Context you can define the aggregates. There can be one or more per BC. Also, some things might not be an aggregate. For example, the Medical History might not require an actual aggregate if it's basically a record of treatment Ids and the dates they were made and there's no business logic associated (the history is not going to deny a treatment, have opinions on when a treatment should happen and so on, it's just a history).
Don't take this as a recommended design, but just as a thought process to come up with your own solution.
Entities have an Id where as Value Objects have structure identity which means if two value objects have the same value then they are the same.
In case of Money, there is no difference between two $5 bills, so it can be a value object.
You have not described the role and attributes of Tooth and Signature.
In case of Tooth, does it matter whose Tooth is it? Can You replace a patient's tooth with any other tooth which has the same attributes? If it does matter, then Tooth requires an Id therefore it is an entity.
In case of Signature, how are you going to compare two signatures? Do you have an image recognition software that can compare the look of two Signatures and decide that they are the same? You might have two patients with similar looking signatures, should their signature be treated as the same?
If you choose Medical history to be an Aggregate, then you should treat it as one object. Do you want to load the entire Medical history, in order to add a new Treatment to it? Can a Treatment be associated with another Entity, such as Dentist? If you can use a portion of Medical history (such as Treatment) individually then it is not an aggregate.
Some good tutorials:
Entity vs Value Object by Vladimir Khorikov
Entities, Value Objects, Aggregates and Roots by Jimmy Bogard
Hello I have just started using Aerospike so I need some details what will be the good data model for my e-commerce platform, I am not able to design a data model for this in Aerospike which can work perfectly.
Here are some basic requirements for my e-commerce platform:
1.>User Set(For login & register an basic information of user)
2.>Product Set (For storing product info like name and image and options and color options etc)
3.>Order Set ( To track record of the user order )
The complex requirement for the special Set required for database is as follows:
1.For each product that a user will buy a Share Code will be generated which a user can share with his/her friends and family to get benefits for future.
2.The user who buys a product with somebody’s Share code, then the details that this user bought the “xyz” product must be transferred to the owner of the share code and also a Share code for this user will also be generate which he/she can share with his/her friend.
3.And also the user must be able to know how many persons shared his/her code an also the user’s who buys a product from the share code of the 1st level user’s Share Code.
So I want to keep record of the users 2 level below the current user.
Looks like you are trying to model a Multi-Level-Marketing order management system.
User and Product are straight forward. Records TTL = live for ever, never delete for all sets. user_info, product_info may be updated.
For simplicity, each product purchase is just one product_id.
By PK I mean the primary key of the record.
User Set: {PK:user_id, user_info:{.....}}
Product Set: {PK:product_id, product_info:{.....}}
Order Set: {
PK: order_id,
order_details:{buyer:user_id,
item:product_id, qty:...,
share_code: "order_id:xyz",
parent_code:"parent_order_id:abc" },
level1_orders:[List of order_ids],
level2_orders:[List of order_ids]
}
The share_code is composite string comprising the order_id:some_code.
For first set of orders (level 0 orders) parent_code may be zero.
Consider order_id = 213, share code: "213:abc", parent_code:"112:pqr"
If any user purchases using share code "213:abc", and this level 1 purchase order_id is 310, make entry in Order set for {PK:310, ... share_code:"310:cde", parent_code:"213:abc", ....} then update order_id=213 - to its level1_orders list, append 310 order_id.If order 213 has a parent_code, in this case it is "112:pqr" also update order_id 112 in its Level2 order lists by appending this order_id, 310 to it.
Now you have all the info you need for your model.
Note: This is a multi-record update model. Be mindful of potential inconsistencies if client fails midway or other bad things happen. There are advanced techniques to address that situation.
However, this may be a good starting point for you. Let me know if this was helpful. If it is different than what you wanted (your part 3 was not very clear to me), you may have to modify the model but the technique highlighted may be helpful.
I'm working on a project for a customer, and one of the requirements is that Users should be allow to assign to each Product (in their case, a Node) a Country or a Region, where the Region is simply a group of Countries, not necessarily in the same area.
I've seen there are many different ways to manage a list of Countries, often suggesting to use Taxonomy for them, but I can't figure out how could I allow users to create these "Regions". To make things complicated, customer wants to have a simple interface, where only one field is present on the form. In this field, Users must be able to choose either a Country or a Region.
Perhaps I could implement everything using Nodes, i.e.:
- Country Nodes
- Region Nodes, with a multiple-valued Node Reference to Country Nodes
But I wonder if that would not be too heavy...
I hope the issue is clear, if not feel free to ask and I'll try to explain it better. Thanks for all suggestions.
I ended up creating my own tables and code to handle the whole thing, as I couldn't find any better solution. I used tables from IP2Country module as a source for Country Codes.