It actually quite simple as Eric Evans and @Thomas Owens mentioned

Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book prevents an extensive set of design practices, techniques, and principles.

In other words it is just a set of pattern to solve issues when building an application. Such as @Ewans mentioned :

"I have a big program but whenever I ask for a change the developers say its hard/impossible because of the way they have written it. Things that seem obvious to me like 'Orders can be cancelled' apparently require a whole redesign of what an 'Order' is.?!?"

It uses the methods such as:

• have a common language - UbiquitousLanguage practice of building up a common, rigorous language between developers and users.
• ModelDrivenSoftwareDevelopment- centers on building models of a software system
• Bounded Context - segregating the application into different spheres

Each point has for more points and nuances and can be check out in the referenced books.

N.B.: most of the time it boils down to many established principles such as SOLID with more abstract approach considering the user domain when drawing out the system. In comparison, to class/implementation side in SOLID.

It is actually quite simple as Eric Evans and @Thomas Owens mentioned

Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book prevents an extensive set of design practices, techniques, and principles.

In other words it is just a set of pattern to solve issues when building an application. Such as @Ewans mentioned :

"I have a big program but whenever I ask for a change the developers say its hard/impossible because of the way they have written it. Things that seem obvious to me like 'Orders can be cancelled' apparently require a whole redesign of what an 'Order' is.?!?"

It uses the methods such as:

• have a common language - UbiquitousLanguage practice of building up a common, rigorous language between developers and users.
• ModelDrivenSoftwareDevelopment- centers on building models of a software system
• Bounded Context - segregating the application into different spheres

Each point has for more points and nuances and can be check out in the referenced books.

N.B.: most of the time it boils down to many established principles such as SOLID with more abstract approach considering the user domain when drawing out the system. In comparison, to class/implementation side in SOLID.

It actually quite simple as Eric Evans and @Thomas Owens mentioned

Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book prevents an extensive set of design practices, techniques, and principles.

In other words it is just a set of pattern to solve issues when building an application. Such as @Ewans mentioned :

"I have a big program but whenever I ask for a change the developers say its hard/impossible because of the way they have written it. Things that seem obvious to me like 'Orders can be cancelled' apparently require a whole redesign of what an 'Order' is.?!?"

It uses the methods such as:

• have a common language - UbiquitousLanguage practice of building up a common, rigorous language between developers and users.
• ModelDrivenSoftwareDevelopment- centers on building models of a software system
• Bounded Context - segregating the application into different spheres

Each point has for more points and nuances and can be check out in the referenced books.

N.B.: most of the time it boils down to many established principles such as SOLID with more abstract approach considering the user domain when drawing out the system.

It actually quite simple as Eric Evans and @Thomas Owens mentioned

Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book prevents an extensive set of design practices, techniques, and principles.

In other words it is just a set of pattern to solve issues when building an application. Such as @Ewans mentioned :

"I have a big program but whenever I ask for a change the developers say its hard/impossible because of the way they have written it. Things that seem obvious to me like 'Orders can be cancelled' apparently require a whole redesign of what an 'Order' is.?!?"

It uses the methods such as:

• have a common language - UbiquitousLanguage practice of building up a common, rigorous language between developers and users.
• ModelDrivenSoftwareDevelopment- centers on building models of a software system
• Bounded Context - segregating the application into different spheres

Each point has for more points and nuances and can be check out in the referenced books.

N.B.: most of the time it boils down to many established principles such as SOLID with more abstract approach considering the user domain when drawing out the system. In comparison, to class/implementation side in SOLID.