Can we use value object in command ?
Suppose I have a Shop (aggregate) in which there is one value object Address.
In the value object constructor Address ,I was put the some validation logic for address.
So if I am using that Address object in command (CreateShopCmd) , then it get validated at the making of command , but What I want or Read that validation should be present in command handler.
But problem is that , I have to put that validation again in command handler (Since validation is already present in it Address constructor) and if I am not putting that in command handler , then the validation will occur when I am making the Address object in event handler and assign to Shop aggregate(Which is incorrect)
So, please guide me.
Below are code example
#Aggregate
#AggregateRoot
public class Shop {
#AggregateIdentifier
private ShopId shopId;
private String shopName;
private Address address;
#CommandHandler
public Shop(CreateShopCmd cmd){
//Validation Logic here , if not using the Address in
// in cmd
//Fire an event after validation
ShopRegistredEvt shopRegistredEvt = new ShopRegistredEvt();
AggregateLifecycle.apply(shopRegistredEvt);
}
#EventSourcingHandler
public void on(ShopRegistredEvt evt) {
this.shopName = evt.getShopName();
//Validation happend here if not put in cmd at the time of making
//Address object - this is wrong
this.address = new Address(evt.getCity(),evt.getCountry(),evt.getZipCode())
}
}
public class CreateShopCmd{
private String shopId;
private String shopName;
private String city;
private String zipCode;
private String country;
}
public ShopCreatedEvent{
private String shopId;
private String shopName;
private String city;
private String zipCode;
private String country;
}
There is nothing conceptually wrong with using Value Objects in Commands or Events. However, you should use them with caution.
The structure of a Message may change over time. If you have used Value Object excessively inside your messages, it may become less clear how a change in one of the value objects changes the structure of different messages.
For Value Objects that represent a "common" concept, such as an Address, this is not so much of a problem. But as soon as the Value Objects become more domain-specific, this may come up as an issue.
This is a very good question and I have been thoroughly thinking about embedding value objects in commands or not. I came to the conclusion you should definitely not use Value Objects in commands:
Commands are part of the application layer, they are supposed to work as simple as possible, avoiding any typed objects, and work best using literal (think serialization). What happen when an external system wants to plugin on your hexagon (application layer) and send commands to your application, do they need your command library to be able to use the objects and the structure defined ? Hell no ! You don't want that, so keep command simple.
Another reason is, as DmitriBodiu said, VO contains business logic and validation, they belong to the domain layer, do not ever put them in commands. Application service will do the translation, and be responsible of throwing validation error to any non conforming commands at the client.
There is nothing wrong in your design, its actually how Vaughn Vernon (the author of Implementing Domain Driven Design - IDDD book) did in his repository, you might want to check the application layer at this link:
https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_identityaccess/src/main/java/com/saasovation/identityaccess/application/IdentityApplicationService.java
Notice how he reconstruct every objects from flat commands to value object belonging to the domain layer:
#Transactional
public void changeUserContactInformation(ChangeContactInfoCommand aCommand) {
User user = this.existingUser(aCommand.getTenantId(), aCommand.getUsername());
this.internalChangeUserContactInformation(
user,
new ContactInformation(
new EmailAddress(aCommand.getEmailAddress()),
new PostalAddress(
aCommand.getAddressStreetAddress(),
aCommand.getAddressCity(),
aCommand.getAddressStateProvince(),
aCommand.getAddressPostalCode(),
aCommand.getAddressCountryCode()),
new Telephone(aCommand.getPrimaryTelephone()),
new Telephone(aCommand.getSecondaryTelephone())));
}
Commands must not contain business logic, so they cannot carry a value object.
I wouldn't suggest using Value Objects in commands. Cause your commands are part of the application layer, but Value Objects are kept in Domain Layer. You can use your ValueObjects in DomainEvens though. Because if domain model changes, modification of your domain event wouln't be that painful, cause the modification is done in the same bounded context. You should never use ValueObjects in integration events though.
Short answer: Have you ever thought about Integer, String, Boolean, etc.? Those are Value Objects, too. The only difference is, that you didn't create them yourself. Now try to build a Command without any Value Objects ;-)
Long answer:
In general I don't see any issue with Value Objects within Commands. As long as you follow a few simple guidelines:
The most important code in your application is your Domain Model. The Domain Model defines the data structures it expects for Command handling. This means: The only reason to change your Command Model is if your Domain Model requires this change. The same applies to your Value Objects: Value Objects only change if this change is required by your Domain Model. No exceptions!
Commands can in general fail either because of business constraints, or because of invalid data (or because of optimistic locking, or whatever).
As said above: Integers and Strings are Value Objects, too. If you only use basic types within your Command, it will already throw an exception if you try new SetAgeCommand(aggId, "foo"), because String cannot be assigned to int. The same applies if you don't provide an Aggregate ID to your UpdatePersonCommand. These are no business constraints, but instead very basic data and type validation. Your Command will never be created if you pass malformed data.
Now let's say you have a PersonAge Value Object. I doesn't matter where you construct this object, because in any case it must throw an Exception if you try to construct it with a negative number: -5 cannot be assigned to PersonAge - looks familiar? As long as you can make sure that your code created those Value Object instances, you can know for sure that they are valid.
Business rules should be checked by the Command Handler within your Domain Model. In general business constraints are specific to your Domain, and most often they rely on the data within your Aggregate. Take for example SendMoneyCommand. Your Money Value Object can validate if it's a valid currency, but it cannot validate if the user's bank account has enough money to execute the transaction. This is a business validation and it's part of your Domain Model.
And a word regarding Events: I'd suggest to only use very basic Value Objects inside your events. For example: String, Integer, Date, etc. Basically every kind of Value Object that will never change. The reason behind it: Business requirements can change. For example: Maybe your Domain Model requires your Address Value Object to change, and it's now required to provide geo-coordinates. Then this will implicitly change your NewAddressAddedEvent. But your already persisted Events didn't have this requirement, though you're unable to construct Address Value Objects from your past event data, because the new Address Value Object will throw an Exception if there are no geo-coordinates provided.
There are (at least) two solutions for this problem:
Versioned Events: After modifying your Address Value Object, you have now a NewAddressAddedEvent_Version2 which uses the new Address Value Object, and you have the old NewAddressAddedEvent which must use a backup copy of the old Address Value Object.
Write a Script that "repairs" your event database by adding geo-coordinates to every Event that uses the Address Value Object. So you can throw away the old NewAddressAddedEvent.
That's OK as long as the value objects are conceptually a part of your message contract, and not used in entities.
And if they are a part of your entity, don't expose them as public properties of your message or you'll be in soop.
I've been banging my head on this problem for a week, and now I'm starting to understand what's going on, but no idea why, or how to fix it.
Let me describe what I'm doing. I have an assortment of various objects in Java, and I have a native library. Java objects inform the library of their existence by calling NativeLibrary.AddObject(this). The native library has a container of jobjects where I store global references to the Java objects, obtained with env->NewGlobalRef(object). The native library uses these stored references to access the Java objects, and it does work fine.
And here's the crucial part that does NOT work. Obviously, I want to be able to delete Java objects, not only add them. So, when a Java object is no longer needed, it calls NativeLibrary.RemoveObject(this). The native library implements it by iterating the list of stored objects (which are all global references, as you may remember) and finding a match with env->IsSameObject(passedObject, storedObjectGlobalReference).
And here's where the problem is: it doesn't work as expected, the Java objects are not matched to their global references properly. When I started digging and logging all the calls with all the parameters, I noticed a weird thing: the jobject parameter of the native call (which is this of Java objects) has the same value for different objects! Moreover, this value changes between the ``NativeLibrary.AddObject(this)andNativeLibrary.RemoveObject(this)` calls for the same object!
So, what's going on, and how can I store, keep track of and delete the references to Java objects in native code? To reiterate: everything works fine as long as I only create and store global refs; the correct objects receive notifications via these refs, no problem. But as soon as I try deleting these references via env->DeleteGlobalRef, I find out that in the NativeLibrary.RemoveObject(this) implementation fails to match the stored reference to the passed jobject.
I was with the same problem. The root cause was that the added item NativeLibrary.AddObject(this) not was the same object when I called NativeLibrary.RemoveObject(this). I was using junit and this was causing the problem, because junit create multiples objects to run each test. I found the problem using System.out.println with the object in Java side. Before add function System.out.println("add object: " + sameObject); and before remove function System.out.println("remove object: " + sameObject);. Sorry for poor english, I hope this help someone.
My problem is exactly the same as you can read in this thread:
stackoverflow thread
But there is a small difference. I try to explain it using the above thread's image.
The CS relationship contains C type objects as it is described, but also contains E type objects too, because the E type objects are derived from the C type object.
On thread's image the E type object is not present and this is the difference. The E type property also has a CS relationship.
The problem comes when I try to reach the E type object's CS property using the following query: SUBQUERY(bs, $x, ANY $x.cs.cs ....
The query is not finished, but the important code is there. As I observed, the predicate creation fails, because it tries to use the CS relationship on the C type object. I've tried to use the CAST operator on the $x.cs variable without success.
Do anybody has a clue for this?
Edit: Added image
The values of the MKMultiAttribute entity can contain MKAttribute and MKMultiAttribute types. And this is the problem, because the values is set to be a relationship to MKAttribute, but, because MKMultiAttribute is derived from MKAttribute the values can contain MKMultiAttribute entities and currently I can't call the values again.
Node.js will do auto garbage collections ?
var objUser = new Object ();
objUser.userName = objReq.userName;
userDB.registerUser (objUser , callback) ;
In the above code I have "objUser" which will be passed as an argument to another class and it is no longer required in the present class. Still, should I have to forcefully collect it or will it do automatically.
To do it manually, Will NULL help or is there any other mechanism given by Node Framework?
objUser = null;
Node does garbage collection, but if userDb.registerUser() retains a reference to it, your objUser will not be collected. Only when no references to an object remain it will be collected. You usually don't need to explicitly release local references by assigning null to the variable — when your function returns, all local references are released automatically. You need to worry only about global references to your object.
Also worth noting on this subject: It's been my experience that objects of the same type will reuse instances. So, if you truly want a "new Instance()" of an object make sure you nullify or reset any attributes in your constructors
I'm using db4o with groovy (actually griffon). I'm saving dozen of objects into db4o objectSet and see that .yarv file size is about 11Mb. I've checked its content and found that it stores metaClass with all nested fields into every object. It's a waste of space.
Looking for the way to avoid storing of metaClass and therefore reduce the size of result .yarv file, since I'm going to use db4o to store millions of entities.
Should I try callConstructors(true) db4o configuration? Think it would help?
Any help would be highly appreciated.
As an alternative you can just store 'Groovy'-beans instances. Those are compiled down to regular Java-ish classes with no special Groovy specific code attached to them.
Just like this:
class Customer {
// properties
Integer id
String name
Address address
}
class Address{
String street;
}
def customer = new Customer(id:1, name:"Gromit", address:new Address(street:"Fun"))
I don't know groovy but based on your description every groovy object carries metadata and you want to skip storing these objects.
If that is the case installing a "null translator" (TNull class) will cause the "translated" objects to not be stored.
PS: Call Constructor configuration has no effect on what gets stored in the db; it only affects how objects are instantiated when reading from db.
Hope this helps