From f440731ea4275010af779732c9e4a49fdf0ac01a Mon Sep 17 00:00:00 2001 From: Ludwig Muench Date: Sun, 24 Nov 2019 10:42:21 -0500 Subject: [PATCH 1/5] add ddd guide --- ddd.md | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 ddd.md diff --git a/ddd.md b/ddd.md new file mode 100644 index 0000000..68e2519 --- /dev/null +++ b/ddd.md @@ -0,0 +1,45 @@ +# Domain-Driven Design + +## Ubiquitous Language +#### Problem +A client requests a feature or reports a problem to a PM. The PM creates a Jira issue and assigns it to an engineer. The engineer reads the issue and there is a lot of room for interpretation to what there is to be done. + +#### Technique +Everyone involved in the project should speak a common language that prevents ambiguity while talking about domain logic. This ubiquitous language is the intersection of technical and business terms that is relevant for both sides. + +"Use the model as the backbone of a language. Commit the team to using that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and, especially speech. + +Iron out difficulties by experimenting with alternative expressions, which reflect alternative models. Then refactor the code, renaming classes, methods and modules to conform to the new model. Resolve confusion over terms in conversation, in just the way we converge on agreed meaning of ordinary words." [1] + + +## Bounded Context +#### Problem +"Multiple models are in play on any large project. They emerge for many reasons. Two subsystems commonly serve very different user communities, with different jobs, where different models may be useful. Teams working independently may solve the same problem in different ways through lack of communication. The tool set may also be different, meaning that program code cannot be shared." [2] + +#### Technique +"Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas." [2] + + +## Model-Driven Design +#### Problem +Once you start to design software based on your models of the domain you usually find reasons to depart from the original models. + +#### Technique +"Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious." [2] As soon as you start depart from it: "Revisit the model and modify it to be implemented more naturally in software". [2] + +"Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code. The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model." [2] + + +## Domain Events +#### Problem +"An entity is responsible for tracking its state and the rules regulating its lifecycle. But if you need to know the actual causes of the state changes, this is typically not explicit, and it may be difficult to explain how the system got the way it is." [2] + +#### Technique +"Model information about activity in the domain as a series of discrete events. Represent each event as a domain object. These are distinct from system events that reflect activity within the software itself [...] +A domain event is a full-fledged part of the domain model, a representation of something that happened in the domain. Ignore irrelevant domain activity while making explicit the events that the domain experts want to track or be notified of, or which are associated with state change in the other model objects. [...] + +Domain events are ordinarily immutable, as they are a record of something in the past. In addition to a description of the event, a domain event typically contains a timestamp for the time the event occurred and the identity of entities involved in the event. Also, a domain event often has a separate timestamp indicating when the event was entered into the system and the identity of the person who entered it. When useful, an identity for the domain event can be based on some set of these properties. So, for example, if two instances of the same event arrive at a node they can be recognized as the same." [2] + +## Sources +[1] Domain-Driven Design, Eric Evans, 2003 +[2] Domain-Driven Design Reference, Eric Evans, 2015 From a66873a022ed12c49f469a2d22e36db8632f8256 Mon Sep 17 00:00:00 2001 From: Ludwig Muench Date: Sun, 24 Nov 2019 10:44:44 -0500 Subject: [PATCH 2/5] remove bounded context section --- ddd.md | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/ddd.md b/ddd.md index 68e2519..253f924 100644 --- a/ddd.md +++ b/ddd.md @@ -12,14 +12,6 @@ Everyone involved in the project should speak a common language that prevents am Iron out difficulties by experimenting with alternative expressions, which reflect alternative models. Then refactor the code, renaming classes, methods and modules to conform to the new model. Resolve confusion over terms in conversation, in just the way we converge on agreed meaning of ordinary words." [1] -## Bounded Context -#### Problem -"Multiple models are in play on any large project. They emerge for many reasons. Two subsystems commonly serve very different user communities, with different jobs, where different models may be useful. Teams working independently may solve the same problem in different ways through lack of communication. The tool set may also be different, meaning that program code cannot be shared." [2] - -#### Technique -"Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas." [2] - - ## Model-Driven Design #### Problem Once you start to design software based on your models of the domain you usually find reasons to depart from the original models. @@ -42,4 +34,5 @@ Domain events are ordinarily immutable, as they are a record of something in the ## Sources [1] Domain-Driven Design, Eric Evans, 2003 + [2] Domain-Driven Design Reference, Eric Evans, 2015 From c4c47be6d6dde01ce723a74a6837da35c2c3271f Mon Sep 17 00:00:00 2001 From: Ludwig Muench Date: Sun, 24 Nov 2019 10:49:29 -0500 Subject: [PATCH 3/5] format text --- ddd.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ddd.md b/ddd.md index 253f924..7d112e2 100644 --- a/ddd.md +++ b/ddd.md @@ -14,7 +14,7 @@ Iron out difficulties by experimenting with alternative expressions, which refle ## Model-Driven Design #### Problem -Once you start to design software based on your models of the domain you usually find reasons to depart from the original models. +Once you start to design software based on your model of the domain you usually find reasons to depart from the original model. #### Technique "Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious." [2] As soon as you start depart from it: "Revisit the model and modify it to be implemented more naturally in software". [2] @@ -28,10 +28,12 @@ Once you start to design software based on your models of the domain you usually #### Technique "Model information about activity in the domain as a series of discrete events. Represent each event as a domain object. These are distinct from system events that reflect activity within the software itself [...] + A domain event is a full-fledged part of the domain model, a representation of something that happened in the domain. Ignore irrelevant domain activity while making explicit the events that the domain experts want to track or be notified of, or which are associated with state change in the other model objects. [...] Domain events are ordinarily immutable, as they are a record of something in the past. In addition to a description of the event, a domain event typically contains a timestamp for the time the event occurred and the identity of entities involved in the event. Also, a domain event often has a separate timestamp indicating when the event was entered into the system and the identity of the person who entered it. When useful, an identity for the domain event can be based on some set of these properties. So, for example, if two instances of the same event arrive at a node they can be recognized as the same." [2] + ## Sources [1] Domain-Driven Design, Eric Evans, 2003 From c7cb83030a5f59ff7b4efaaf0275b96667d9dbab Mon Sep 17 00:00:00 2001 From: Ludwig Muench Date: Sun, 24 Nov 2019 16:14:29 -0500 Subject: [PATCH 4/5] link to DDD Reference PDF --- ddd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ddd.md b/ddd.md index 7d112e2..569367a 100644 --- a/ddd.md +++ b/ddd.md @@ -37,4 +37,4 @@ Domain events are ordinarily immutable, as they are a record of something in the ## Sources [1] Domain-Driven Design, Eric Evans, 2003 -[2] Domain-Driven Design Reference, Eric Evans, 2015 +[2] [Domain-Driven Design Reference, Eric Evans, 2015](http://domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf) From e2eafcca63dcfacd0a6db48c36b8505badc98f05 Mon Sep 17 00:00:00 2001 From: Ludwig Muench Date: Mon, 25 Nov 2019 09:14:37 -0500 Subject: [PATCH 5/5] add missing word --- ddd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ddd.md b/ddd.md index 569367a..9b317d9 100644 --- a/ddd.md +++ b/ddd.md @@ -17,7 +17,7 @@ Iron out difficulties by experimenting with alternative expressions, which refle Once you start to design software based on your model of the domain you usually find reasons to depart from the original model. #### Technique -"Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious." [2] As soon as you start depart from it: "Revisit the model and modify it to be implemented more naturally in software". [2] +"Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious." [2] As soon as you start to depart from it: "Revisit the model and modify it to be implemented more naturally in software". [2] "Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code. The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model." [2]