Yes - we know that DDD is way more than just a data model - but if you don’t get at least your data right, your system is likely to fail…

In case you don’t create and document a full-blown ‘domain driven design’ model containing both static and dynamic aspects, you should at least create and document a (business- or domain) data model.

Such a data model gives an overview of the fundamental data structures of the system and their relevant relationships.

Take the following as a brief example (based upon an idea from uml-diagrams.org). It lacks definitions or further explanations of the entities and their relations… in reality, you should be more thorough…

brief example for a data model, hospital domain

PlantUML source

The diagram above was automatically generated from the following PlantUML source:

@startuml

interface Person {
title: String
lastName: String
firstname: String
birthData: Date
gender: Gender
postalAddress: Address
}

Person "1" -left- "1..*" Phone

Person <|-- Patient
Person <|-- Staff

Person "*" --right-- "*" Hospital

class Hospital {
name: String
address: Address
}

class Department {
name: String
location: String
}


Department "*" -down-* "1" Hospital
Department "1" -- "1..*" Staff
(Department, Staff) -- Contract

Hospital --- "1..*" Phone

class Phone {
telNr: String
isPrivat: Boolean
}

class Staff {
joined: Date
education: String[]
certificate: String[]
languages: String[]
}

class Contract{
begin: Date
isUnlimited: Boolean
monthSalary: Float
contractType: ContractType

}

class Patient {
id: String {id}
name: String
aufgenommen: Date
allergie: String[]
aktuelleDiagnose: Diagnosis[]
}

Staff <|-down- MedicalStaff
Staff <|-down- AdministrativeStaff
Staff <|-down- TechnicalStaff


class MedicalStaff{
fachrichtung: String[]
approbation: Boolean

}

MedicalStaff -left-  Patient

class AdministrativeStaff {
}

class TechnicalStaff {
}

@enduml