What is the difference between a domain class diagram and a design class diagram?

A domain model is called conceptual model in database modeling, while a design model is called logical model.

These distinctions are also used in model-driven development, where we have a succession of three types of models:

1. (solution-independent) domain models resulting from domain/requirements engineering in the system analysis, or inception, phase of a development project;
2. (platform-independent) design models resulting from the system design activities in the elaboration phase and typically based on a domain model;
3. (platform-specific) implementation models, which may be (e.g., JavaScript or Java EE) class models, SQL table models or other types of data models derived from an information design model.

While system modeling includes both information and process modeling, you seem to be concerned with information modeling only. Here, we can use the terms "domain class diagram" and "design class diagram" for the conceptual information model and the information design model made in the form of UML class diagrams.

The one-to-many relationships between conceptual models and design models, and between design models and implementation models are illustrated in the following Figure:

Considering information/class/data modeling we get the following picture:

As an example that illustrates how the derivation chain from concept via design to implementation works, consider the following model of a people/Person concept/class:

Domain models are solution-independent descriptions of a problem domain produced in the analysis phase of a software engineering project. The term "conceptual model" is often used as a synonym of "domain model". A domain model may include both descriptions of the domain’s state structure (in conceptual information models) and descriptions of its processes (in conceptual process models). They are solution-independent, or ‘computation-independent’, in the sense that they are not concerned with making any system design choices or with other computational issues. Rather, they focus on the perspective and language of the subject matter experts for the domain under consideration.

In the design phase, first a platform-independent design model, as a general computational solution to the given software engineering problem, is developed on the basis of the domain model. The same domain model can potentially be used to produce a number of (even radically) different design models representing different design choices. Then, by taking into consideration a number of implementation issues ranging from architectural styles, nonfunctional quality criteria to be maximized (e.g., performance, adaptability) and target technology platforms, one or more platform-specific implementation models are derived from the design model.

See also the Open Access book chapters Information Modeling and Deriving a Table Model from an Information Design Model.

If your focus is on the diagram itself, there are two big differences between diagrams about domain model and diagrams about design model: (At least this is what the Larman book Applying UML and Patterns says)

1. In UML diagrams which represent domain model, you cannot use arrows. All classes are interlinked with a line, which signifies "relation", and you should use text annotations over the lines to illustrate what relation it exactly is. While in design models, you have to use arrows, all types of arrows: association, inheritance... etc

2. In design model you have to specify the type of properties and methods etc, while in domain model you only have to write them without anything additional(just like in real world). For example, value: int in design model will be written as value in domain model.

Reference: Applying UML and Patterns 3rd Edition Chapter 9 and 16.