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 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:


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 {