What is a correct way of designing REST API's for SpringBoot - spring-restcontroller

As I know about designing of REST-API's in SpringBoot we will design API's for User like
For ADD User = /v1/users (Add a single object into a user collection)
For GET/UPDATE/DELETE user = /v1/users/{userId} (for get/update/delete
a single object from users collection)
Now We also design an API's for User Address like
For Add Address = /v1/users/{userId}/addresses (Add a single object
into addresses of user followed by userId)
For GET/UPDATE/DELETE = /v1/users/{userId}/addresses/{addressId}
(get/update /delete of address from addresses for a user of given
userId)
So, I have created API's like this but for add/get/update/delete I can direct addresses into Address table via RestController -> Services -> Repository -> DB
Now for Address CRUD I'm never used {userId} which is provided in API
Sample for Add/Update address
#Override
public Address addAddress(Address address) {
address = addressRepository.save(address);
return address;
}
Is there I'm doing something wrong in code or my concept about rest is not cleared.
Thank you in advance.

I think first you should come up with the structure of relationship between user and address.
Like ADDRESS CANT EXISTS WITHOUT USER and USER CAN HAVE MANY ADDRESSES or CAN HAVE ONLY ONE ADDRESS that is basically the cardinality of the relationship.
See the accepted anwer.
Once that done and you come up with the CASCADE TYPE and USE THE HELPER method persist the parent along with child.
Here is the good example.
Will try to upload code for your example.
Let me know of this:)
EDIT:
#Entity
#Getter
#Setter
#ToString
#NoArgsConstructor
#AllArgsConstructor
public class User {
private Long id;
private String userName;
#OneToMany(cascade = CascadeType.ALL, mappedBy = "user", orphanRemoval = true)
private List<Address> addresses = new ArrayList<>();
public void addAddress(Address address) {
addresses.add(address);
address.setUser(this);
}
public void removeAddress(Address address) {
address.setUser(null);
this.addresses.remove(address);
}
}
#Entity
#Getter
#Setter
#ToString
#NoArgsConstructor
#AllArgsConstructor
public class Address {
private Long id;
private String address;
#ManyToOne
private User user;
}
public class Service
{
#PostMapping(value="/saveAddressForUser")
public void saveAddressForUser(#RequestBody AddressForUser address)
{
User user=getUserFromDatabase(userId);
user.addAddress(address);
Repository.persist(user);//it will also persist address as cascade type is all.
}
}

Related

How do I create an Entity Framework DbSet with data from 2 tables

Before I start my question, I will point out that this is for an assignment in a programming course I am doing, and I'm afraid the code needs to be in VB.
Scenario:
We are writing an app to help manage a veterinary clinic. There is a legacy MySQL database which cannot be changed. Information relating to pets and their owners are stored in two separate tables ("pets" table and "owners" table, and the tables are linked by the FK of CustomerId. We are able to use our choice of data access technologies and ORMs, and I have chosen to use EF to take advantage of the Change Tracking (I'd prefer to not have to write this code).
What I need to do is create an Entity Framework DbSet that contains information from both the pet and owner tables. I have looked at Table splitting in EF, but the two "entities" of pet and owner do not have the same primary key (which as I understand Table Splitting is required).
I have reviewed the following articles, and they have not helped:
Entity Framework and DbSets
DbSet in Entity Framework
Return data from two tables with Entity Framework
I am using EF6 and the "Code First from existing Database" workflow.
My Pet class looks like (I've removed the auto generated data annotations for brevity):
Partial Public Class Pet
Public Sub New()
bookings = New HashSet(Of Booking)()
stays = New HashSet(Of Stay)()
End Sub
Public Property petID As Integer
Public Property petName As String
Public Property species As String
Public Property breed As String
Public Property DOB As Date?
Public Property gender As String
Public Property weight As Single?
Public Property customerID As Integer?
Public Overridable Property bookings As ICollection(Of Booking)
Public Overridable Property customer As Customer
Public Overridable Property stays As ICollection(Of Stay)
End Class
My Customer class:
Partial Public Class Customer
Public Sub New()
pets = New HashSet(Of Pet)()
End Sub
Public Property customerID As Integer
Public Property title As String
Public Property firstName As String
Public Property lastName As String
Public Property gender As String
Public Property DOB As Date?
Public Property email As String
Public Property phone1 As String
Public Property phone2 As String
Public Property street1 As String
Public Property street2 As String
Public Property suburb As String
Public Property state As String
Public Property postcode As String
Public Overridable Property state1 As State
Public Overridable Property pets As ICollection(Of Pet)
Public ReadOnly Property FullName() As String
Get
Return $"{Me.lastName}, {Me.firstName}"
End Get
End Property
End Class
I also have a PetInfo class that does NOT map to the DB:
Public Class PetInfoModel
Public Property PetID As Integer
Public Property PetName As String
Public Property Species As String
Public Property Breed As String
Public Property DOB As Date
Public Property Gender As String
Public Property Weight As Decimal
Public Property OwnerFirstName As String
Public Property OwnerLastName As String
Public ReadOnly Property OwnerName() As String
Get
Return $"{OwnerLastName}, {OwnerFirstName}"
End Get
End Property
End Class
Now for the hard part: I would like to be able to use the PetInfoModel as a DbSet in my context to take advantage of the EF change tracking.
If it makes any difference (I don't think it should), I am using WPF MVVM and Caliburn.Micro for the UI. The ultimate goal is to get a List bound to a WPF datagrid.
Any assistance or suggestions would be more than welcome. Thanks for your time and efforts.
Regards
Steve Teece
I'm not very familiar with VB, so I'll have to write the answer in C#, I think you get the gist.
So you have DbSet<Pet> Pets and DbSet<Customer> Customers and you want to create something that acts as if it was a DbSet<PetInfoModel> PetInfoModels.
Are you sure you want something that acts like a DbSet? You want to be able to Add / Find / Attach / Remove PetInfoModels? Or do you only want to query data?
Problems with PetInfoModel
It seems to me that you get into troubles, if you want to Add a new PetInfoModel with a zero PetId, and the name of an existing Customer:
Add(new PetInfoModel
{
PetId = 0;
PetName = "Felix"
OwnerFirstName = "John",
OwnerLastName = "Doe",
Species = "Cat",
...
});
Add(new PetInfoModel
{
PetId = 0;
PetName = "Nero"
OwnerFirstName = "John", // NOTE: Same owner name
OwnerLastName = "Doe",
Species = "Dog",
...
});
Do we have one Customer with two Pets: a Cat and a Dog? Or do we have two Customers, with the same name, each with one Pet?
If you want more than just query PetInfoModels (Add / Update / Remove), you'll need to find a solution for this. I think most problems will be solved if you add a CustomerId. But then again: your PetInfoModel would just be a subset of the properties of a "Pet with his Owner", making it a bit useless to create the idea of a PetInfoModel
Anyway: let's assume you've defined a proper PetInfoModel and you really want to be able to Create / Retrieve / Update / Delete (CRUD) PetInfoModels as if you have a database table of PetInfoModels.
Database versus Repository
You should realize what your DbContext represents. It represents your database. The DbSet<...> properties of your DbContext represent the tables in your database. Your database does not have a table with PetInfoModels, hence your DbContext should not have this table.
On the other hand: Quite often you'll see a wrapper class around your DbContext that represents the things that can be stored in your Repository. This class is usually called a Repository.
In fact, a Repository only tells you that your data is stored, not how it is stored: it can be a CSV-file, or a database with a table structure different than the data sequences that can be handled by your repository.
IMHO I think it is wise to let your DbContext represent your database and create a Repository class that represents the stored data in a format that users of your database want.
As a minimum, I think a Repository should be able to Create / Retrieve / Update / Delete (CRUD) Customers and Pets. Later we'll add CRUD functions for PetInfoModels.
Customers and Pets
A RepositoryItem is something that can be stored / queried / removed from the repository. Every RepositoryItem can be identified by a primary key
interface IRepositoryItem<TRepositoryItem> : IQueryable<TRepositoryItem>
where TRepositoryItem : class
{
TRepositoryItem Add(TRepositoryItem item);
TRepositoryItem Find (params object[] keyValues);
void Remove(TRepositoryItem item);
}
To guarantee this primary key, I created an interface IID and let all my DbSet classes implement this interface. This enhances Find and Remove:
interface IID
{
int Id {get; }
}
class Student : IId
{
public int Id {get; set;}
...
}
interface IRepositoryItem<TRepositoryItem> : IQueryable<TRepositoryItem>
where TRepositoryItem : IID
{
TRepositoryItem Add(TRepositoryItem item);
TRepositoryItem Find (int id);
void Remove(TRepositoryItem item);
// or remove the item with primary key:
void Remove(int id);
}
If we have a DbSet the implementation of an IRespositoryItem is easy:
class RepositoryDbSet<TRepositoryItem> : IRepositoryItem<TRepositoryItem>
where TRepositoryItem : class
{
public IDbSet<TRepositoryItem> DbSet {get; set;}
public TRepositoryItem Add(TRepositoryItem item)
{
return this.DbSet.Add(item);
}
public TRepositoryItem Find (params object[] keyValues)
{
return this.DbSet.Find(keyValues);
}
public void Remove(TRepositoryItem item)
{
return this.DbSet.Remove(item);
}
public void Remove(TRepository
// implementation of IQueryable / IEnumerable is similar: use this.DbSet
}
If you defined interface IID:
public TRrepositoryItem Find(int id)
{
return this.DbSet.Find(id);
}
public void Remove(int id)
{
TRepositoryItem itemToRemove = this.Find(id);
this.DbSet.Remove(itemToRemove);
}
Now that we've defined the class that represents a set in the Repository, we can start creating the Repository itself.
class VetRepository : IDisposable
{
public VetRepository(...)
{
this.dbContext = new DbContext(...);
this.customers = new RepositoryItem<Customer> {DbSet = this.dbContext.Customers};
this.pets = new RepositoryItm<Pet> {DbSet = this.dbContext.Pets};
}
private readonly DbContext dbContext; // the old database
private readonly IRepositoryItem<Customer> customers;
private readonly IRepositoryItem<Pet> pets;
// TODO IDisposable: Dispose the dbcontext
// Customers and Pets:
public IRepositoryItem<Customer> Customers => this.customers;
public IRepositoryItem<Pet> Pets => this.pets;
IRepositoryItem<PetInfoModel> PetInfoModels = // TODO
public void SaveChanges()
{
this.DbContext.SaveChanges();
}
// TODO: SaveChangesAsync
}
We still have to create a repository class that represents the PetInfoModels. This class should implement IRepositoryItem. This way users of the repository won't notice that the database doesn't have a table with PetInfoModels
class RepositoryPetInfoModel : IRepositoryItem<PetInfoModel>
{
// this class needs both Customers and Pets:
public IDbSet<Customer> Customers {get; set;}
public IDbSet<Pet> Pets {get; set;}
public PetInfoModel Add(PetInfoModel petInfo)
{
// check the input, reject if problems
// decide whether we have a new Pet for new customer
// or a new pet for existing customer
// what to do with missing fields?
// what to do if Customer exists, but his name is incorrect?
Pet petToAdd = ... // extract the fields from the petInfo
Customer customerToAdd = ... // or: customerToUpdate?
// Add the Pet,
// Add or Update the Customer
}
Hm, do you see how much troubles your PetInfoModel encounters if you really want to CRUD?
Retrieve is easy: just create a Query that joins the Pet and his Owner and select the fields for a PetInfoModel. For example
IQueryable<PetInfoModel> CreateQuery()
{
// Get all Customers with their Pets
return this.Customers.Join(this.Pets
{
customer => customer.Id, // from every Customer take the primary key
pet => pet.CustomerId, // from every Pet take the foreign key
// Result selector: take every Customer with a matching Pet
// to make a new PetInfoModel
(customer, pet) => new PetInfoModel
{
CustomerId = customer.Id,
OwnerFirstName = customer.FirstName,
...
PetId = pet.Id,
PetName = pet.Name,
...
});
}
Update is also fairly easy: PetId and CustomerId should exist. Fetch the Pet and Customer and update the fields with the corresponding fields from PetInfoModel
Delete will lead to problems again: what if the Owner has a 2nd Pet? Delete only the Pet but not the Owner? Or Delete the Owner and all hist Pets, inclusive the Pets you didn't mention?
Conclusion
If you only want to query data, then it won't be a problem to introduce a PetInfoModel.
To really CRUD PetInfoModels, you'll encounter several problems, especially with the concept of Owners with two Pets, and Owners having the same name. I would advise not to CRUD for PetInfoModels, only query them.
A proper separation between your database and the concept of "stored data" (Repository) is advisable, because it allows you to have a database that differs from the model that users of your Repository see.

Invoking custom Jackson deserializers inside of other deserializers

I am writing a Spring Boot app (RESTful webservice) that uses Jackson for serialization. I have the following data models that will be sent back and forth between the service and its HTTP clients (hence these will be serialized/deserialized to/from JSON):
public abstract class BaseEntity {
#JsonIgnore
private Long id;
private UUID refId;
// Getters, setters, ctors, etc.
}
public abstract class BaseLookup extends BaseEntity {
private String name;
private String label;
private String description;
// Getters, setters, ctors, etc.
}
public class State extends BaseLookup {
private String abbrev; // "VT", "FL", etc.
// Getters, setters, ctors, etc.
}
public class Contact extends BaseEntity {
private String givenName;
private String surname;
private State state;
// Getters, setters, ctors, etc.
}
public class Account extends BaseEntity {
private Contact contact;
private String code;
// lots of other fields that will be generated server-side
// Getters, setters, ctors, etc.
}
Thus there will be some endpoints for CRUDding Accounts, others for CRUDding Contacts, etc. For instance, the AccountController will expose endpoints for CRUDding Account instances:
#RestController
#RequestMapping(value = "/accounts")
public class AccountController {
#RequestMapping(method = RequestMethod.POST)
public void createAccount(#RequestBody Account account) {
// Do stuff and persist the account to the DB
}
}
I want to simplify the JSON that HTTP clients must craft in order to create new Account, Contact, etc. instances. At the same time there are fields on those data models that I do not want exposed to the client-side. Things like the BaseEntity#id (which is the PK of the entity in the DB). Or for instance, in the case of State, I just want the client-side to know about (and use) the abbrev field, etc. I don't want them to ever see the other BaseLookup fields or even know about them.
Hence, my end goal is to allow the client to POST the following JSON, and have a custom Jackson deserializer convert that JSON into an Account instance:
{
"contact" : {
"givenName" : "Him",
"surname" : "Himself",
"state" : "NY"
},
"code" : "12345"
}
So you see, like I stated above, this JSON accomplishes several things:
The client-side doesn't provide a BaseEntity#id or BaseEntity#refId when POSTing to create a new instance
For the contact.state field, which is a BaseLookup with several fields (id, refId, name, label, description, abbrev), the user only has to provide the abbrev field, and the deserializer is expected to figure out which State the client is referring to
The Account class actually has many other fields that are inferred/generated server-side; the client doesn't need to know about them in order to create an Account instance
The JSON above is a simplified form of what we would get if we serialized an Account with Jackson's default behavior; this is to make things easier on the client-side and even more secure on the server-side (not exposing PKs, etc.)
The important thing to note here is that the JSON sent to this controller for the contact field is identical to the JSON that will be POSTed to a ContactController for creating new Contact instances.
Here's the problem:
public class AccountDeserializer extends StdDeserializer<Account> {
public AccountDeserializer() {
this(null);
}
public AccountDeserializer(Class<Account> accClazz) {
super(accClazz);
}
#Override
public Account deserialize(JsonParser jsonParser, DeserializationContext dCtx)
throws IOException, JsonProcessingException {
JsonNode jsonNode = jsonParser.codec.readTree(jsonParser)
Contact contact = ??? // TODO: How to invoke ContactDeserializer here?
String accountCode = node.get("code").asText();
// Generate lots of other Account field values here...
Account account = new Account(contact, accountCode, /* other fields here */);
return account;
}
}
Since I will also have a ContactController (for CRUDding Contact instances irrespective of an associated Account), and because I have similar desires to hide Contact fields from the client-side as well as to simplify the JSON coming into this ContactController#createContact endpoint, I will also need a ContactDeserializer in addition to this AccountDeserializer...
public class ContactDeserializer extends StdDeserializer<Contact> {
// ...etc.
}
This ContactDeserializer will be responsible for converting JSON into Contact instances. But since Account instances also contain Contact instances, and because the "contact JSON" inside the outer "account JSON" will be the same as any JSON that the client sends to any of the "contact endpoints", I'd like to invoke the ContactDeserializer from inside the AccountDeserializer somehow.
That way, when the ContactController receives "contact JSON" to create a new Contact instance, the ContactDeserializer is engaged to get the job done. And, if the AccountController receives "account JSON" to create a new Account instance, then the AccountDeserializer is engaged to get that job done...and it uses the ContactDeserialzer to handle the deserialization of the account JSON's internal contact field as well.
Can this be done?! Can one Jackson deserializer reuse other deserializers inside of it? If so, how? If not, then what's the solution here?!
You can invoke ContactDeserializer by calling the treeToValue method of ObjectCodec. Jackson will automatically pick up the ContactDeserializer for you if you've registered it on your ObjectMapper.
public class AccountDeserializer extends JsonDeserializer<Account> {
#Override
public Account deserialize(JsonParser p, DeserializationContext ctx) throws IOException {
JsonNode node = p.readValueAsTree();
JsonNode contactNode = node.get("contact");
Contact contact = null;
if (contactNode != null) {
contact = p.getCodec().treeToValue(contactNode, Contact.class);
}
return new Account(contact, /* account properties */);
}
}
Edit
If you want to add your deserializers to existing mapper which is created by Spring Boot, you can autowire it in one of your configuration classes and customize as you like.
#Configuration
public class ObjectMapperConfiguration {
#Autowired
public void configureObjectMapper(ObjectMapper mapper) {
SimpleModule module = new SimpleModule()
.addDeserializer(Account.class, new AccountDeserializer())
.addDeserializer(Contact.class, new ContactDeserializer());
mapper.registerModule(module);
}
}

Can't fetch certain types of nested objects in Ebean

I'm trying to fetch nested objects in Ebean, but it isn't working. I get the User. It has Addresses. The Addresses each have a House. But the House only has an id. All other properties are null. I read on this other forum that there may be a bug in Ebean, but it was from 2011. Is there a way to make this work?
Note: Address and House have a OneToOne relationship.
Note: I left out #Entity and #Id for simplicity.
public class User {
#OneToMany
public List<Address> addresses;
public static Finder<String, User> find = new Finder(String.class, User.class);
// This is my query
public static Event find(Long id) {
return find.fetch("addresses").fetch("addresses.house").where().eq("id", id).findUnique();
}
}
public class Address {
#OneToOne(cascade = CascadeType.ALL, mappedBy = "address")
public House house;
}
public class House {
#OneToOne
public Address address;
public String somePropertyThatIsNullWhenIUseMyQuery;
}
Ebean.find(User.class).fetch("addresses.house", new FetchConfig().query())
works for me. If you still dont see it, u might want to use
Address.getHouse().getSomeProperty()
Sometimes when u just pass the object to JSON f.e. properties shown as null :(

Am I breaking the "Law of Demeter"?

I just recently became aware of the Law of Demeter.
Like a lot of things, I realized that it was something that I was already doing but did not have a name for. There are a few places though that I seem to violate it.
For example...
I might have an Address object:
public class Address : IAddress
{
public string StreetAddress { get; set; }
public string City { get; set; }
public int Zip { get; set; }
}
and a Customer object:
public class Customer : ICustomer
{
private IAddress address;
Customer()
{
Address = null;
}
public string Name { get; set; }
public IAddress
{
get
{
if (address == null)
{
address = new Address();
}
return address;
}
set
{
address = value;
}
}
}
Ok, this is fake code so you probably do not have to jump on me to use IoC to eliminate the new Address() or anything but it is pretty much an example of what I am doing. I did not include the interfaces as I am hoping they are obvious.
I would then use it in my code for stuff like int zip = customer.Address.Zip; and customer.Address.City = "Vancouver";
As I understand it, I am violating the Law of Demeter by manipulating details of Address from Customer.
Then again, it seems like the framework does as well. After all, wouldn't address.City.Length be a violation? Should I be adding methods to Address to handle accessing string properties? Probably not. So, why clutter up Address?
I cannot really just add methods to Address that relate only to customer. I have Member, Employee, Dependent, Vendor, Employer, etc. objects that all have addresses too.
Is there a better way to handle this? What kinds of problems am I risking if I use Address the way I am now?
For the Java folks, the Address class might look something more like the following if it helps:
public class Address extends AddressInterface
{
private String m_city;
public String getCity() { return m_city; }
public void setCity(String city) { m_city = city; }
}
I must admit that customer.getAddress().setCity("Vancouver"); rings more alarms than customer.Address.City = "Vancouver"; did for me. Maybe I should switch to Java for a while.
This article: http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx has a great explanation of the issues you are discussing.
As he notes it's not a dot counting exercise, it's a coupling issue. Currently your Customer and Address classes are too tightly coupled. For starters, Customer shouldn't be making new addresses, perhaps pass an Address in using a constructor. As to whether you should be using multiple dots to access parts of the address, read the article ...
Martin Fowler: "I'd prefer it to be called the Occasionally Useful Suggestion of Demeter."
Violations of the Law of Demeter are instances of a code smell named Inappropriate Intimacy. To remove this smell, you can refactor your code by hiding the internals of address and implementing methods in Customer that delegate to address. This way, you respect the encapsulation on the address inside the Customer.
Example:
public class Customer extends ICustomer{
private Address address;
....
public void setCity(String city){
address.setCity(city);
}
public String getCity(){
return address.getCity();
}
}
Hope this helps.
The problem here is that Address is a ValueObject. You would never change the city without changing the zip.
public class Customer extends ICustomer{
private Address address;
....
public void setAddress(String street, String city, int zip){
address = Address.new(street, city, zip);
}
// or even better but i'm not sure if it's valid C#
public void setAddress(int zip){
address = Address.lookup(zip);
}
}

WCF serialization and Value object pattern in Domain Driven Design

The book Domain Driven Design by Eric Evans describes pattern called value object. One of the important characteristics of a value object is that it is immutable.
As an example I have a value object "Clinic" which must have a name and an id. To make it a value object I do not provide setters on name and id. Also to make sure that there is not invalid instance I take name and id in a constructor and do not provide at parameter less constructor.
public class Clinic
{
public Clinic(string name, string id)
{
Name = name;
Id = id;
}
public string Name{get; private set;}
public string Id{get; private set;}
}
The problem is that when I try to return this object from a WCF Service I get an exception that the object does not have parameter less constructor and the properties do not have public setters. I want to avoid adding parameter less constructor and public setters because then my domain model pattern goes for a toss. How can I get around this problem?
Regards,
Unmesh
I had a similar problem with serializing immutable types before, in the end I decided to implement the ISerializable interface and use the SerializationInfo to store & retrieve the private variables at both ends of the serialization/deserialization process:
http://theburningmonk.com/2010/04/net-tips-making-a-serializable-immutable-struct/
I just built and run a test app using the same technique and it seems to work for me. So in terms of changes to your Clinic class you could change it to:
[Serializable]
public class Clinic : ISerializable
{
public Clinic(string name, string id)
{
Name = name;
Id = id;
}
public Clinic(SerializationInfo info, StreamingContext context)
{
Name= info.GetString("Name");
Id= info.GetString("Id");
}
public string Name{get; private set;}
public string Id{get; private set;}
[SecurityPermission(SecurityAction.Demand, SerializationFormatter = true)]
public void GetObjectData(SerializationInfo info, StreamingContext context)
{
info.AddValue("Name", Name);
info.AddValue("Id", Id);
}
}
This will solve the problem you're having passing the data back from WCF. But from a design point of view, I agree with what Ladislav is saying and typically you will want to separate your domain objects with objects purely intended for message passing (DataTransferObjects), and in that case here's an example of how you MIGHT approach it:
// the domain object (NOT EXPOSED through the WCF service)
public class Clinic
{
public Clinic(string name, string id)
{
Name = name;
Id = id;
}
public string Name{ get; private set;}
public string Id{ get; private set;}
// other methods encapsulating some business logic, etc.
...
}
// the corresponding DTO object for the domain object Clinic
// this is the type exposed through the WCF layer, that the client knows about
[DataContract]
public class ClinicDTO
{
[DataMember]
public string Name { get; set; }
[DataMember]
public string Id { get; set; }
}
// WCF service contract, NOTE it returns ClinicDTO instead of Clinic
[ServiceContract]
public interface IClinicService
{
[OperationContract]
ClinicDTO GetClinicById(string id);
}
To ease the pain of converting from Clinic to ClinicDTO, you could either add a method on Clinic to do this or implement an implicit/explicit converter. I've got an example on how to do this here:
http://theburningmonk.com/2010/02/controlling-type-conversion-in-c/
Hope this helps!
The problem is that your value object is not serializable. How do you plan to use the service? Do you plan to share domain objects / value objects with your clients? If yes than it IMO violates your domain driven desing - only business layer should be able to work with domain objects and call their methods. If you don't want to share objects you will probably create proxy by add service reference which will generate data contrats for the client. These contrats will have public parameterless constructor and all properties settable (and no domain methods).
If you want to have real Domain driven design you should not expose your domain objects in WCF. Instead you should create set of DTO and expose those DTOs. Service layer will be responsible of converting those DTOs to Domain objects / value objects and vice-versa.