Optaplanner VRP with Pickups Before DropOffs - optaplanner

I am working on using Optaplanner to solve the following a complex vrp problem with many requirements. I was able to handle most of them except for the following 2 aspects.
Pickups before DropOffs only
Enforce a specific path on the way to pickup customers.
The goal is to pickup a group of customers who are going to destinations that close together and put them in the same vehicle.
Thanks in Advance! I appreciate the help!
The Problem is very similar to the example VRP TimeWindow example but with the following changes.
Customers will be picked up at fixed locations (in a circuit)
Every pickup Customer will have a drop off destination (outside of
Circuit)
The vehicle will not head to a drop-Off then come back to pickup
again. (Once vehicle leaves circuit all it does is drop-Off its
customers at set location)
The Vehicle moving in the circuit has to move in a specific path
(imagine a 1 way street)
Planning on Using Road Distances with the Score between each Pickup-to-Pickup is Known. Pickup -> Drop-Off is not known (Planning on using Air).
I'm having a hard time in enforcing that after leaving the circuit to drop-Off customers a vehicle may not come back to pickup more customers, and having this work with the fixed path a vehicle can make in the circuit.
My main idea was to do the following.
Added a TYPE attribute to the customer to differentiate between pickup & customer
Added a variable listener to the customer class that keep track of all the DropOffIds currently when a vehicle arrives to it so that it only goes to a dropOffLocation if it has a passenger heading to that place. When a vehicle arrives to a dropOff it removes that item from the list. (Essentially serves as a stack).
The problem is theoretically this isn't stopping from a vehicle picking up a customer dropping him off then picking up another, if the customers locations are relatively close.
Also having a hardtime enforcing a fixed route a vehicle must take in a circuit, was planning on using a Cost Matrix to use the soft constraint to enforce the route implicitity(A vehicle wont go backwards or a skip a point as the cost would be too high), but not working the way it should be.

I might consider a domain model like this:
#PlanningEntity
class Pickup implements PickupOrVehicle {
Customer customer;
#PlanningVariable
PickupOrVehicle previousPickup;
#PlanningVariable
int dropOffPriority;
}
#PlanningEntity // Shadow entity
class Vehicle implements PickupOrVehicle {
...
#ShadowVariable(based on dropOffPriority and previousPickup)
List<Customer> dropOffOrderList;
// For consistency we might also add pickUpOrderList
}
That dropOffPriority should either be globally unique (by initializing it uniquely and only configure SwapMoves for that variable.
Or otherwise, the VariableListener should just order 2 assignments with the same dropOffPriority by their customer's id (because the ordering must be deterministic!).
No sure if it will work well. If you do try it out, do let us know here if it works well or not.

Related

DDD - Entity vs ValueObject

I was reading about DDD and I realize that sometimes an entity might be a VO or VO might be an entity. You can know which one is better depends on the context. I was checking different examples. For example, shopping cart DDD example. Product is an aggregate root, Cart is an aggregate root and items is a entity of Cart, so if you want to add a product to the cart you would do something like this:
$cart->addProduct(id $id, $name, $price)
class Cart
{
private items;
function addProduct(ProductId $id, ProductName $name, ProductPrice $price) {
this->items[] = new Item(
new ItemProductId($id->ToString()),
new ItemName($name->ToString()),
new ItemPrice($price->ToString()),
new ItemCartId(this->id->ToString())
);
}
}
There are two reasons why I think it is a VO:
You cannot modify the value's item ( only if the product's
price has been modify there is a event that would modify its price).
The item doesn't have id, it's has a reference of the
product(ItemProductId) and a reference of the cart (ItemCartId)
I was reading about DDD and I realize that sometimes an entity might be a VO or VO might be an entity. You can know which one is better depends on the context.
Usually its pretty clear whats entity and whats an value object. If it contains data that's fixed at the time of assignation, its a value object. For example "order address" on the order aggregate. When the order is placed, the address is set. "Addresses" may be an entity in user aggregate (i.e. a list of his common addresses), but for an order its an value object since its not supposed to change when the user edits or deletes one of his addresses.
cart->addProduct(id $id, $name, $price)
class Cart
{
private items;
function addProduct(ProductId $id, ProductName $name, ProductPrice $price) {
this->items[] = new Item(
new ItemProductId($id->ToString()),
new ItemName($name->ToString()),
new ItemPrice($price->ToString()),
new ItemCartId(this->id->ToString())
);
}
}
That's a pretty bad example. Why would or should the value object be ItemPrice? Does that makes it any special? Why string? A price is usually just a numeric value but also involves a currency, passing it as string kinda beats that.
On top of that, having ItemCartId in the it does
a) leak data persistence knowledge into your domain. The fact, it's contained inside this->items[] already establishes a relationship between the entity (or aggregate) and the value object. ItemCartId as no meaning in the domain, other than that it's required for relational database engines (=persistence knowledge)
There are two reasons why I think it is a VO:
You cannot modify the value's item ( only if the product's price has been modify there is a event that would modify its price).
You sure? Why would a eCommerce business want to have the prices in the card anyways?
Prices are informational only, they could change before the order is placed. Same as availability.
A lot of users put stuff in their cart and check on next day. In that time, the price could change.
No company would want to sell a product for the price when it was put into the shopping cart, if the price increased in the time since it was put in there. That would mean a financial loss.
Prices in the shopping carts are informational, not compulsory. You need know the exact process of the company.
The item doesn't have id, it's has a reference of the product(ItemProductId) and a reference of the cart (ItemCartId)
Again. Why do you think ItemCartId belongs to the Item object? That's leaked persistence knowledge, since its only important for relational database systems.
All you really need in a shopping cart is
* product or article number (not necessary the id, that's typically db knowledge)
* quantity
Nothing else. If you may want to change the user when the price changed and show the old and new price, the take the price (=currency value object, not ItemPrice) to it too as a value to compare to an old state.
Finally and probably most importantly: Consider if the shopping cart is an aggregate at all (or does fit into ddd).
After all, most shopping carts are only a value bag w/o a lot of business logic into it. The real logic (checking the real price, product availability, asking for shipping location, calculation of taxes and shipping costs) happens during the checkout process, not while putting stuff into the cart.
For example you can check out eShops on Containers demo project showing an example shopping service based on microservices and ddd.
Some microservices apply DDD (such as Ordering microservice), where others don't (Catalog microservice or the Basket (cart) Microservice).
Applying DDD doesn't mean everything needs to be done with DDD. If its simple crud based services, then you don't need DDD for these. DDD adds a value where you have complex systems and complex business logic.
A catalog has neither, it just presents data which come from a different system (i.e. ERP which on other side may be built on using DDD).
I don't understand what are you asking exactly, but the code you are providing could be improved.
First of all I suggest you to read the red book by Vaughn Vernon https://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577: you can find 3 chapters describing how to define entities, value objects and aggregates, with some rules of thumbs.
One of those advices, is to keep your aggregates as small as possible, in order to improve your performance and keep the code easy to read and maintain. Imagine that you have a Blog aggregate that contains a list of Post entities: if you manage all of them in a single aggregate, when you want to modify the blog Author, for example, you are forced to retrieve all of the blog's post, without any reason, and that means that you are doing a join and slowing down your application. The more your aggregates grows, the slower those queries with their joins.
So, in the case of the Cart, I suggest you to build the cart without any item or product, instead you can add the CartId to the Item. Cart does not know which items it contains, but items know in which cart they are.
About value objects: is a tool that allows you to wrap some validation and business logic inside a class that is represented by its state and not by its id (like entities), so in the case of the cart, if you put two identical bottles of water inside it, how can you know that they are different? Do you need to know that they are different? Are they different if they are physically (or logically different) or are they different if some of their attribute is different?
In my opinion an item or a product, in your case, are entities because they are not measuring anything, and when you put an item twice, you actually have two different items (and you use an id to recognize them).
This is not necessary like this, sometime you can use a value object and sometimes an entity, it depends on your context. A good example to understand that difference is with money:
if you want to measure an amount, for example 10 dollars, probably a value object will work for you, because you don't care if it a bill or another, you just want to measure 10 dollars; in this case if you have 10 dollars, is not important if you have a bill or another, the important thing is that is 10 and not 5
in the case that you need to recognize different physical bills, for any reason (you need to track money for the police), you should use an entity, because any printed bill has a unique serial number, and a 10 dollar bill, in this context, is actually different from another 10 dollar bill
Hope this can help you.
Goodbye!

Modeling lunch breaks and additional depot returns in Optaplanner

we are using optaplanner to try to improve our current vehicle routes with time windows. We have a few smaller issues which we are not sure how to overcome:
Our drivers need to have to have a 30 minutes lunch break, somewhere between 3rd and 5th hour of their shift (from the start of their drive), and if the drive is shorter than 5 hours - no break is required.
We have to make sure that some packages (but not all) get back to the depot by a certain time. For example, some customer would have a pick-up time from 8:00 to 8:30 but their package / parcel has to be returned to depot by 12:00.
Our current idea for the second problem is to create two new classes:
public class ReturningCustomer extends TimeWindowedCustomer {
protected int returningId;
and
public class ReturnToDepot extends TimeWindowedCustomer {
protected int returningId;
where the first one models the customer with special packages, which are to be returned. The second one is the “fake” customer that represents the driver’s return to the depot. ReturnToDepot would have the same location as the depot itself. Comparing their ids in Drools will assure that they are on the same vehicle’s path. Treating the ReturnToDepot as another customer would hopefully assure that the planner finds an optimal way to put it into a route.
However, for the lunch break modeling, we are not quite sure what to do.
Is there a better way to model this? What would be the best way to model the lunch breaks? Are there any samples which could point us to the right direction?
Thanks.
Starting from the TimeWindowed VRP examples, you can do those 2 reqs like this:
Lunch breaks: adjust the arrivalTime calculation in the VariableListener so that any arrival after the 3th hour will add another 30 minutes to the arrivalTime. Depending on your business needs - for example they can only take a break between locations not at locations - optionally add a hard constraint to assure there's an arrival between the 3th and 5th hour.
Get back in time to depot: add a shadow variable on Vehicle called arrivalBackToDepotTime and use variableListenerRef to reuse the ArrivalTimeUpdateVariableListener which then also needs to update that field. Add a hard constraint to check for each Customer that the Vehicle's arrivalBackToDepotTime is less than the Customer's required time to get to the depot.

Does optaplanner out of box support VRP with multiple trips and no depot

I am working on a VRP with the following characteristics:
The vehicle can only pick up 1 customer at one time
The vehicle picks up a customer at a location and drops off the customer at the destination
After dropping off the customer the vehicle goes on to pick up another customer
There is no depot that vehicle needs to go to in between the trips .
The vehicle makes as many trips as it can in a day to pickup/drop-off customers
At the end of day, the vehicle goes back to its designated parking station
Essentially, it's like a taxi system. It seems to me that it's a VRP with multiple trips(VRPMT) and no depot (Open VRP). I'd like to know
Does optaplanner has support for VPRMT and OVRP out of box?
If VPRMT and OVRP are not supported out of box, how easy is it to modify the existing CVRP/CVRPTW examples to make it solve OVRP and VPRMT?
Maybe I am on the wrong track and it's not even a VRP. If so, what would be the right planning problem for the taxi like system?
Many thanks in advance!
No, the examples don't include pickup and delivery or multiple trips yet
Users have done it before to add Pickup and Delivery (which is easy if multiple customers cannot be in the vehicle at the same time (otherwise it's harder and I might add an example for that way some day). Multiple trips and open VRP should by easy (although I think your parking station is a depot and you probably don't have multiple trips, just multiple customer sequentially in the same trip).
This is definitely a variant of VRP. Do note that every business has their own flavor of VRP. You'll always find some custom constraints (now or later in the development process). OptaPlanner allows you to add those custom constraints as needed.
Try this: Take the OptaPlanner VRP example, rename Depot to ParkingStation. Split up Customer's Location into pickupLocation and deliveryLocation and adjust the score rules so the soft score is the sum of:
all pickup to delivery distances
all delivery to next pickup distances
each parking to first pickup distance
each last delivery to parking distance

optaplanner: modifying vehicle routing to let customers be not served

In a vehicle routing problem I want to eliminate the constraint that every customer must be served, but adding a prize for those who are served.
I'd like to add a virtual vehicle v_i for each customer c_i, such that v_i can serve only customer c_i, and when it happens it means that the customer is not served. Hence, when there are N customers, there are M real vehicles plus N virtual vehicles.
My doubt is: how can I set the valueRangeProviderRefs of the Customer class to avoid client c_j to be served by vehicle v_i, that is, can I make "vehicleRange" depend on a specific customer instead if refferring to a static List of vehicles?
This is called overconstrained planning. Technically, #PlanningVariable(nullable=true) should allow this, but OptaPlanner 6.0 (and 6.1 currently too) does not support nullable for chained variables yet...
Workaround: Create 1 dummy Vehicle, which is ignored in all the score rules and add a score rule to reward any customer being serviced by a non-dummy Vehicle.

Update an entity inside an aggregate

I was reading a similar question on SO: How update an entity inside Aggregate, but I'm still not sure how a user interface should interact with entities inside an aggregate.
Let's say I have a User, with a bunch of Addresses. User is the aggregate root, while Address only exists within the aggregate.
On a web inteface, a user can edit his addresses. Basically, what happens is:
The user sees a list of addresses on its web interface
He clicks on an address, and gets redirected to this page: edit-address?user=1&address=2
On this page, he gets a form where he can modify this address.
I we decided to bypass the aggregate root, this would be straightforward:
We would directly load the Address with its Id
We would update it, then save it
Because we want to do it the DDD way, we have different solutions:
Either we ask the User to get this Address by Id:
address = user.getAddress(id);
address.setPostCode("12345");
address.setCity("New York");
em.persist(user);
The problem with this approach is, IMO, that the aggregate root still doesn't have much more control over what's done with the address. It just returns a reference to it, so that's not much different from bypassing the aggregate.
Or we tell the aggregate to update an existing address:
user.updateAddress(id, "12345", "New York");
em.persist(user);
Now the aggregate has control over what's done with this address, and can take any necessary action that goes with updating an address.
Or we treat the Address as a value object, and we don't update our Address, but rather delete it and recreate it:
user.removeAddress(id);
address = new Address();
address.setPostCode("12345");
address.setCity("New York");
user.addAddress(address);
em.persist(user);
This last solution looks elegant, but means that an Address cannot be an Entity. Then, what if it needs to be treated as an entity, for example because another business object within the aggregate has a reference to it?
I'm pretty sure I'm missing something here to correctly understand the aggregate concept and how it's used in real life examples, so please don't hesitate to give your comments!
No, you're not missing anything - in most cases the best option would be number 2 (although I'd call that method changeAddress instead of updateAdress - update seems so not-DDD) and that's regardless whether an address is an Entity or Value Object. With Ubiquitous Language you'd rather say that User changed his address, so that's exactly how you should model it - it's the changeAddress method that gets to decide whether update properties (if Address is an Entity) or assign completely new object (when it's VO).
The following sample code assumes the most common scenario - Address as VO:
public void ChangeAddress(AddressParams addressParams)
{
// here we might include some validation
address = new Address(addressParams);
// here we might include additional actions related with changing address
// for example marking user as required to confirm address before
// next billing
}
What is important in this sample, is that once Address is created, it is considered valid - there can be no invalid Address object in your aggregate. Bare in mind however, that whether you should follow this sample or not depends on your actual domain - there's no one path to follow. This one is the most common one though.
And yes, you should always perform operations on your entities by traversing through aggregate root - the reason for this was given in many answers on SO (for example in this Basic Aggregate Question).
Whether something is an entity or VO depends on the requirements and your domain. Most of the time address is just a Value Object, because there's no difference between two addresses with the same values and addresses tend to not change during their lifetime. But again, that's most of the time and depends on domain you're modeling.
Another example - for most of the domains a Money would be a Value Object - 10$ is 10$, it has no identity besides amount. However if you'd model a domain that deals with money on a level of bills, each bill would have its own identity (expressed with a unique number of some sort) thus it would be an Entity.