Nazewnictwo obiektów DTO.

Macie jakieś sprawdzone sposoby jak nazywać obiekty DTO? Np. mamy klasę Invoice, która odzwierciedla w 100% tabelę z bazy danych. Następnie serwis filtruje kolekcje tych klas na podstawie jakichś warunków i zwraca obiekt DTO, a API wystawia go na zewnątrz. Teraz pytanie: taki obiekt w zależności od kontekstu potrzebuje tylko część pól z klasy Invoice , ale nieraz potrzebuje także dane z innej klasy. Czy macie jakieś konwencje jak nazywać takie obiekty które są okrojoną wersją jednego obiektu lub zlepkiem danych z dwóch lub więcej obiektów? Czy nazywacie go zgodnie z jakimś kontekstem ? Taki kontekst dosyć trudno określić a z kolei nie podoba mi się jak ktoś nazywa takie obiekty np. InvoiceInfo, InvoiceWithData, InvoiceData, InvoiceBasicContent. To powoduje śmietnik i takie nazwy nic nie mówią. Mało tego zdarza się że klasa InvoiceDTO ma mniej danych niż InvoiceBasicContent. Jak zrobić to dobrze?

Jak wywołuję operację X, to mam XDTO. Mało oryginalne, ale przynajmniej unikam konfliktów nazw i pakietów, bezsensownych nazw niezwiązanych merytorycznie z operacją, a do tego łatwo potem znaleźć ten typ..

@Afish: dopisywanie na końcu nazwy klasy DTO sufiksu DTO jest dla mnie tak oczywiste, że już bardziej być nie może.

...Bo po co zaciemniać sobie spektrum skoro DTO to DTO i nic innego?

Nie mam tu jakiejś wielkiej konsekwencji, ale w sumie nigdy nie nazywam klas EtwasEtwasDTO. Zaczynam design od frontu (API) i to tzw. DTOsy są moimi pierwszymi klasami,
mają nazwy obiektów domenowych, ale czasem też od operacji (zależy).
Natomiast te perzystentne to dziwadła i dostają przyrostki (BlaBlaData , BlaBlaRecord).