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…

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