Design Patterns are very technical patterns in code, while Domain Patters are conceptual patters in the model.
Some times, we have different ways in which we can perform an action, a process. In order to decide which strategy we are going to use at run time, we will eventually have a conditional.
In a naive approach we would have a method with as many conditionals as strategies to to perform the action, and all strategies coded directly in that same method. An approach which is a bit better, is to have a method for each different strategy, but still in the same class.
Using the STRATEGY design pattern, we create a class per each strategy algorithm. All of those strategy classes will implement a common interface so that the calling code can use either strategy class without caring which one it is actually executing. This will completely decouple the calling code from the concrete implementation of the different strategies.
The calling code will then use an ABSTRACT FACTORY to instantiate the appropriate strategy class according to a SPECIFICATION.
The composite pattern tries to simplify the usage of a complex structure of an object, by modelling that structure in as a tree where all elements are of the same type.
An example can be the products categories of a webshop. In this case, we have the categories completely decoupled from the products. It doesn’t really matter what products the category has inside. A category can have several categories inside, and those can have other categories in them, and so forth, so on, building the mentioning tree like structure where all elements have the same interface.
The example given by Eric Evans, is about travel routes, where each route is composed by an origin, a destination, and several smaller routes which are composed by even smaller routes and so on.