Modeling Cash-Case differences - should WebAPI DTO's be flat? I have an n-layer application with domain models and DTOs models. 

My DTOs are going through entire application(every layer) and also I return them from my WebAPI. It is good approach?

Basically, if my DTOs go out app by API they should be flat or not?

Flat:

public class CashCase
{
    public string Id;
    public string Title;
    public DateTime Opened;

    public decimal DifferenceAmount;
    public decimal DifferenceOriginalAmount;
    public decimal DifferenceOriginalFcyAmount;
    public CashCaseDifferenceCurrency DifferenceCurrency;
    public CashCaseDifferenceSource DifferenceSource;
    public CashCaseDifferenceType DifferenceType;
}
public enum CashCaseDifferenceCurrency
{
    PLN
}
public enum CashCaseDifferenceSource
{
    ATM,
    [EnumMember(Value = "ATM Offsite")]
    ATMOffsite,
    Cash
}
public enum CashCaseDifferenceType
{
    Surplus, Deficiency
} 


Not flat:

public class CashCase
{
    public string Id;
    public string Title;
    public DateTime Opened;

    public CashCaseDifference Difference;
}
public class CashCaseDifference
{
    public decimal Amount { get; set; }
    public decimal OriginalAmount;
    public decimal OriginalFcyAmount;
    public CashCaseDifferenceCurrency Currency { get; set; }
    public CashCaseDifferenceSource Source { get; set; }
    public CashCaseDifferenceType Type { get; set; }
}
public enum CashCaseDifferenceCurrency
{
    PLN
}
public enum CashCaseDifferenceSource
{
    ATM,
    [EnumMember(Value = "ATM Offsite")]
    ATMOffsite,
    Cash
}
public enum CashCaseDifferenceType
{
    Surplus,
    Deficiency
}


What would be the best style?

Make them flat if they will be exposed outside applications? I think I don't want expose my inner domain structure to world.
My vote is for not-flat, for several reasons:


The names of the members are less redundant, both in code and over the web
Code is more easily testable. If ever there is a method that deals only with the "difference" fields, there's less surface area to deal with than if you had to manipulate an entire CashCase.
Cardinality. If ever there comes a time that you need to remodel the application to support more than one "difference", having a CashCaseDifference class makes that effort trivial.