Merge pull request #8 from isaqb-org/changelog-2023.1

Add change log 2023.1

CHANGELOG.md

@@ -1,3 +1,83 @@
-# New in 2022.1
+# New in 2023.1
 
-- Add release notes here
+## Changes in "1. Domain, model, and ubiquitous language"
+- Merged learning goal 1-3 into learning goal 1-2
+- Changed learning goal 1-2: "Understand the role of domain-specific terminology in the construction of a ubiquitous language"
+  - Redefined Ubiquitous Language
+  - Add focus on formalization of the Ubiquitous Language and on the necessity to create it using a collaborative approach
+- Changed ID of learning goal 1-4 to 1-3: "Know and be able to explain the building blocks of domain-driven design"
+- Changed ID of learning goal 1-5 to 1-4: "Know and be able to explain the connections between the building blocks"
+
+## Changes in "2. The path to the model"
+- Renamed chapter
+- Added terms and principles: Agile and evolutionary modeling
+- Changed learning goal 2-7: "Get an overview of Collaborative Modeling, its methods, and how it relates to DDD."
+  - Focus is on common values and principles of Collaborative Modeling techniques
+  - Event Storming is only one possible methods among others (Domain Story Telling, User Story Mapping)
+  - Facilitiation of Event Storming is now part of learning goal 2-9
+- Added learning goal 2-9: "Be able to conduct a collaborative modeling workshop"
+- Added learning goal 2-10: "Understand agility as a foundation of DDD"
+
+## Changes in "3. From the model to implementation"
+- Moved terms and principles to chapter 7:
+  - CRC cards
+- Changed learning goal 3-2: "Be able to model interfaces for domain classes"
+  - Removed CRC cards: Moved to chapter 7
+
+## Changes in "4. The model in the application architecture"
+- Renamed learning goal 4-1: "Be able to design a ports & adapter architecture for the domain model"
+- Moved terms and principles to chapter 7:
+  - Werkzeug- und Materialansatz (WAM)
+- Changed learning goal 4-1: "Be able to design a ports & adapter architecture for the domain model"
+  - Focus on ports & adapter as a collection of architecural approaches
+  - Hexagonal architecure is only one style among others (Onion, Clean)
+  - Remove details regarding hexagonal architecture
+  - Remove CQRS: Moved to chapter 7
+- Changed learning goal 4-2: "Be able to formulate correlations and distinctions between DDD and BDD"
+  - Removed Werkzeug- und Materialansatz (WAM): Moved to chapter 7
+
+## Changes in "5. Cutting and distinguishing models from one another"
+- Renamed chapter to focus on strategic design: "Strategic Design 1: Cutting and distinguishing models from one another"
+- Removed from terms and principles:
+  - Model consistency
+- Moved terms and principles to chapter 6:
+  - Shared Kernel
+  - Customer/Supplier Teams
+  - Open Host Service
+  - Domain Event
+- Added terms and principles:
+  - Problem Space and Solution Space
+  - Subdomain
+  - Core vs supporting vs generic
+- Changed ID of learning goal 5-3 to 5-5: "Be able to describe model boundaries of Bounded Contexts in a Context Map"
+- Changed ID of learning goal 5-7 to 5-6: "Be able to use Domain Events as a means of communication between Bounded Contexts"
+- Changed learing goal 5-2: Conway's Law has only descriptive properties
+- Removed learning goal 5-4: Moved to learning goal 6-4
+- Removed learning goal 5-5: Moved to learning goal 6-1
+- Removed learning goal 5-6: Moved to learning goal 6-2
+- Removed learning goal 5-7: Moved to learning goal 6-6
+- Added learning goal 5-3: Be able to move on from problem to solution space
+- Added learning goal 5-4: Distill the core
+
+## Changes in "6. Maintaining local model consistency"
+- Renamed chapter to focus on context mapping: "Strategic Design 2: Context Mapping"
+- Removed from terms and principles:
+  - Continuous Integration
+- Added terms and principles from chapter 5:
+  - Shared Kernel
+  - Customer/Supplier Teams
+  - Open Host Service
+  - Domain Event
+- Removed learning goal 6-1: Continuous Integration
+- Changed ID of learning goal 6-2 to 6-3: "Be able to isolate your own model from external influences"
+- Changed ID of learning goal 6-3 to 6-5: "Understand the circumstances in which it is appropriate to divide the model (Separate Ways)"
+- Added learning goal 6-1 (former 5-5): "Be able to use interfaces for customer/supplier teams"
+- Added learning goal 6-2 (former 5-6): "Be able to design a system as an open host service (OHS)"
+- Added learning goal 6-4 (former 5-4): "Be able to reuse core elements of several partial models in a shared kernel"
+- Added learning goal 6-6 (former 5-7): "Be able to use Domain Events as a means of communication between Bounded Contexts"
+
+## Introduced "7. Related Topics"
+- Add a new chapter with optional related topics which are not part of the core curriculum
+
+## Changes in "References"
+- Updated list of references

docs/01-module-block-1/02-learning-goals.adoc

@@ -15,15 +15,12 @@ Zudem erhalten die Teilnehmer:innen einen detaillierten Einblick in die verschie
 ==== LZ 1-2: Die Rolle der Fachsprache bei der Konstruktion einer Ubiquitous Language verstehen
 * Die TN verstehen, dass eine gemeinsame Sprache für Domänenexpert:innen und Entwickler:innen dem wechselseitigen Verständnis dient.
 * Die TN verstehen den Begriff der Ubiquity (Allgegenwärtigkeit): "Allgegenwärtigkeit" gilt in einer definierten Grenze (Bounded Context) innerhalb derer die Sprache in Gesprächen, Diagrammen, Dokumentation und Code konsistent verwendet wird.
-
-[[LZ-1-3]]
-==== LZ 1-3: Rolle der Fachsprache bei der Konstruktion einer Ubiquitous Language verstehen
 * Die TN verstehen, dass die grundlegenden Begriffe einer Ubiquitous Language der Fachsprache der Domänenexpert:innen entspringen.
 * Die TN verstehen, dass die Ubiquitous Language eine formalisierte Version der Fachsprache und eine bewusste Entwurfsentscheidung ist.
 * Die TN verstehen, dass sich die Ubiquitous Language im Dialog von Entwicklungsteam und Fachbereich weiterentwickelt.
 
-[[LZ-1-4]]
-==== LZ 1-4: Die Bausteine von Domain Driven Design kennen und erklären können
+[[LZ-1-3]]
+==== LZ 1-3: Die Bausteine von Domain Driven Design kennen und erklären können
 * Die TN verstehen die grundlegenden Bausteine von Domain Driven Design.
 ** Value Objects stellen elementare Wert-Typen aus der fachlichen Welt dar. Sie können nur andere Value Objects enthalten. Value Objects haben keine Identität, sind jedoch
 vergleichbar.
@@ -36,8 +33,8 @@ vergleichbar.
 ** **Repositories** dienen der Bestandsverwaltung von Entities zur Laufzeit. Das Ermitteln und Herausgeben einer Referenz auf ein Entity oder Aggregate zu einem eindeutigen Identifikator fällt in ihren Aufgabenbereich. Hinter ihnen lassen sich Schnittstellen zu Drittsystemen wie Datenbanken oder entfernten Services verbergen.
 ** **Domain Events** unterstützen die Verbreitung von Informationen über das Auftreten von fachlichen Ereignissen. Fachliche Ereignisse werden von Aggregates oder Entities ausgelöst und über ein Publisher/Subscriber-Pattern (vgl. Observer <<gamma>>) an angemeldete Klienten propagiert.
 
-[[LZ-1-5]]
-==== LZ 1-5: Die Zusammenhänge zwischen den Bausteinen kennen und erklären können
+[[LZ-1-4]]
+==== LZ 1-4: Die Zusammenhänge zwischen den Bausteinen kennen und erklären können
 * Die TN sind in der Lage die Bausteine in Beziehung zu setzen und sinnvoll miteinander zu kombinieren (vgl. Übersicht auf Seite 65 <<evans>>]).
 
 // end::DE[]
@@ -59,15 +56,12 @@ The course participants also obtain a detailed insight into the various componen
 ==== LG 1-2: Understand the role of domain-specific terminology in the construction of a ubiquitous language
 * The course participants understand that a common language for both domain experts and developers assists mutual understanding.
 * The course participants understand the term ubiquity: "Ubiquity" applies in a defined boundary (Bounded Context) within which the language is used consistently in conversations, diagrams, documentation, and code.
-
-[[LG-1-3]]
-==== LG 1-3: Understand the role of domain-specific terminology in the construction of a ubiquitous language
 * The course participants know that the fundamental terms of a ubiquitous language originate from the domain experts.
 * The participants understand that the Ubiquitous Language is a formalized version of the domain language and a conscious design decision.
 * The participants understand that the Ubiquitous Language evolves in a dialog between development team and domain experts.
 
-[[LG-1-4]]
-==== LG 1-4: Know and be able to explain the building blocks of domain-driven design
+[[LG-1-3]]
+==== LG 1-3: Know and be able to explain the building blocks of domain-driven design
 * The course participants understand the fundamental building blocks of domain-driven design. o Value Objects represent elementary value types from the domain. They can only
 contain other Value Objects. Value Objects have no identity, but are comparable.
 ** Entities represent things in the domain. They can contain Value Objects and other
@@ -80,8 +74,8 @@ Entities. Entities have an identity.
 ** **Repositories** are used for the inventory management of Entities at runtime. Determining and issuing a reference to an Entity or Aggregate for a unique identifier falls within their area of responsibility. They can be used to hide interfaces to third-party systems such as databases or remote services.
 ** **Domain Events** support the sharing of information about the occurrence of domain-related incidents. Domain Events are triggered by Aggregates or Entities and propagated via a publisher/subscriber pattern (cf. Observer <<gamma>>) to registered clients.
 
-[[LG-1-5]]
-==== LG 1-5: Know and be able to explain the connections between the building blocks
+[[LG-1-4]]
+==== LG 1-4: Know and be able to explain the connections between the building blocks
 * The course participants are able to create a relationship between the building blocks and combine them in a sensible manner (cf. overview on page 65 <<evans>>).
 
 // end::EN[]

docs/04-module-block-4/02-learning-goals.adoc

@@ -4,7 +4,7 @@
 Dieser Block vermittelt anhand ausgewählter Beispiele, wie ein Domänenmodell in Softwarearchitekturen integriert werden kann. Er vermittelt exemplarisch Gemeinsamkeiten und Unterschiede von Domain Driven Design und zwei verwandten Methoden.
 
 [[LZ-4-1]]
-==== LZ 4-1: Eine Ports&Adapter-Architektur um ein Domänenmodell herum entwerfen
+==== LZ 4-1: Eine Ports & Adapter-Architektur um ein Domänenmodell herum entwerfen
 * Die TN können die Unterschiede zwischen einer Ports&Adapter-Architektur (z.B. Hexagonal, Clean oder Onion) und einer Schichtenarchitektur vermitteln.
 
 [[LZ-4-2]]
@@ -18,7 +18,7 @@ Dieser Block vermittelt anhand ausgewählter Beispiele, wie ein Domänenmodell i
 This section uses selected examples to teach how a domain model can be integrated into software architectures. On the basis of examples, it teaches the similarities and differences between domain-driven design and two related methods.
 
 [[LG-4-1]]
-==== LG 4-1: Be able to design a ports&adapter architecture for the domain model
+==== LG 4-1: Be able to design a ports & adapter architecture for the domain model
 * The course participants can explain the differences between a ports&adapter architecture (e.g., Hexagonal, Clean, or Onion) and a layered architecture.
 
 [[LG-4-2]]

docs/06-module-block-6/02-learning-goals.adoc

@@ -83,7 +83,7 @@ This section teaches approaches with which the consistency within a model can be
 * The course participants understand that the teams are equally qualified to work on the shared kernel.
 
 [[LG-6-5]]
-==== LG 6-5: Understand the circumstances in which it is appropriate to divide the model (Separate Ways), taking into account the aspects from section 5.
+==== LG 6-5: Understand the circumstances in which it is appropriate to divide the model (Separate Ways)
 * The course participants can contrast the coordination costs of a common model with the overheads for separate models.
 * The course participants understand that a model must be divided along a sensible boundary.
 * The course participants understand that, in these cases, local model consistency is easier to maintain in two partial models.