V25-LG-3-08, V23-LG-2-5, refactor pattern learning goal

[gernotstarke]

the current LG is too large and contains different kind of patterns.

Split into two distinct (e.g. one for system-wide patterns like layers and microservices) and others related to solving specific and smaller problems.

Move dependency-inversion/detection

[alxlo]

@sko Find out, how we can reduce the size of this LG or at least re-order patterns into a sensible sequence, maybe off-load content to the glossary

[gernotstarke]

@skogsbaer - are you active on this? Any chance to complete until end-of-July?

[skogsbaer]

@gernotstarke I'm midway through the exams. Currently not working on this issue. My plan was to finish to english version in the next week. So end of July should be fine.

[skogsbaer]

Working on this.

[skogsbaer]

So here is my suggestion:

1. LG 03-08 only contains architectural patterns
2. The new LG 03-09 contains the design patterns

With respect to the R1, R3 categorization, nothing changes.

Optionally, we could move the explanations of the patterns to the glossary, linking from the learning goals to the glossary. This would have two benefits:

• The learning goals become shorter and easier to read
• Our glossary gets more complete and consistent with the curriculum

The downside is that it's a lot of work to update the glossary because most patterns in the learning goals do not have an entry in the glossary.

Here is how the two learning goals would look like. I have omitted the descriptions of the patterns, assuming they are in the glossary. At the end, you see what needs to be added to the glossary.

@mikesperber I have moved interpreter and combinator to the design patterns. Is this ok? @gernotstarke @alxlo What do you think about the structure? Any opinion on the glossary?

LG 03-08 [previously LG 2-05]: Describe, Explain and Apply Important Architectural Patterns (R1, R3)

Software architects can explain and provide examples for the following architectural patterns (R1):

• Layer
• Pipes and filters
• Microservice
• Dependency-injection

Software architects can explain several of the following architectural patterns, explain their relevance for concrete systems, and provide examples. (R3)

• Blackboard
• Broker
• CQRS (Command-Query-Responsibility-Segregation)
• Event sourcing
• Integration and messaging patterns (e.g. from <>)
• MVC (Model View Controller), MVVM (Model View ViewModel), MVU (Model View Update), PAC (Presentation Abstraction Control)
• Plug-in
• Ports & adapters (synonyms: Onion-Architecture, Hexagonal-Architecture, Clean-Architecture)
• SOA (Service-Oriented Architecture)

Software architects know essential sources for architectural patterns, such as POSA (e.g. <>) and PoEAA (<>) (for information systems) (R3).

LG 03-09 [previously LG 2-05]: Describe, Explain and Apply Important Design Patterns (R3)

Software architects know the difference between architectural and design patterns. They can explain several of the following design patterns, explain their relevance for concrete systems, and provide examples. (R3)

• Combinator (synonym: closure of operations, see <>, <>)
• Interpreter
• Interfacing patterns like Adapter, Facade, Proxy (<>). Architects should know that these patterns can be used independent of (object) technology
• Observer (<>)
• Remote procedure call
• Template and strategy (<>)
• Visitor (<>)

Software architects know essential sources for design patterns, such as POSA (e.g. <>) and GOF (<>) (R3).

• Layer
• Pipes-filters
• Microservice
• Dependency-injection

Software architects can explain several of the following architectural patterns, explain their relevance for concrete systems, and provide examples. (R3)

Changes to Glossary

• [ ] Layer: glossary needs to be updated
• [ ] Pipes and filters: glossary entry missing
• [ ] Microservice: glossary needs to be updated
• [ ] Dependency-injection: glossary needs to be updated
• [ ] Blackboard: glossary entry missing
• [ ] Broker: glossary ok
• [ ] CQRS (Command-Query-Responsibility-Segregation): glossary is missing the "Requires some context on database-/persistence technology to understand the different properties and requirements of "read" versus "write" operations" part
• [ ] Event sourcing: *glossary entry missing**
• [ ] Integration and messaging patterns (e.g. from <>)
• [ ] MVC (Model View Controller), MVVM (Model View ViewModel), MVU (Model View Update), PAC (Presentation Abstraction Control): MVVM, MVU and PAC are not present in the glossary
• [ ] Plug-in: glossary entry missing
• [ ] Ports & adapters (synonyms: Onion-Architecture, Hexagonal-Architecture, Clean-Architecture): glossary entry missing
• [ ] SOA (Service-Oriented Architecture): glossary entry missing
• [ ] Combinator (synonym: closure of operations, see <>, <>): glossary entry missing
• [ ] Interpreter: glossary entry missing
• [ ] Interfacing patterns like Adapter, Facade, Proxy (<>). Architects should know that these patterns can be used independent of (object) technology: glossary ok
• [ ] Observer (<>): glossary ok
• [ ] Remote procedure call: glossary entry missing
• [ ] Template and strategy (<>): glossary entry missing
• [ ] Visitor (<>): glossary entry missing

[gernotstarke]

I like your suggestion, AND your proposals for improving the glossary. The work needs to be done anyway...

Therefore, go for it, create the LG's, open a PR and I'm happy to accept it :-)

thanx for your valuable contribution and time!

[skogsbaer]

There is a seven year old issue in the glossary tracker: https://github.com/isaqb-org/glossary/issues/82

[skogsbaer]

Here is a PR for the glossary: https://github.com/isaqb-org/glossary/pull/199

[skogsbaer]

Now that the PR for the glossary was accepted, there is a PR for the curriculum: https://github.com/isaqb-org/curriculum-foundation/pull/478

[skogsbaer]

@gernotstarke we can close this, right?

[gernotstarke]

yes, it's completed and done.