diff --git a/README.adoc b/README.adoc
new file mode 100644
index 0000000..a512391
--- /dev/null
+++ b/README.adoc
@@ -0,0 +1,297 @@
+= patterns
+Complete catalog of all classical patterns in the Archimate language (ArchiTool used https://www.archimatetool.com)
+This version includes all 155+ patterns completed (278+ models). Images also available.
+
+- Domain driven design patterns
+- Fowler's Analysis patterns
+- Fowler's Enterprise patterns
+- GoF classical Design patterns
+- Uncle Bob, Robert Martins patterns
+
+It's great opportunity to use best practices in your micro service architecture
+Also avialable at http://arch.expert.life/en/patterns
+
+== See huge examples inside book
+
+image:example1.png[link="example1.png"]
+image:example2.png[link="example2.png"]
+
+== Book avialable also with pdf
+
+image:patternsbookcover.png[link="patterns.pdf"]
+
+== Table of contents
+
+* DESIGN PATTERNS
+** CREATIONAL PATTERNS
+*** ABSTRACT FACTORY
+*** BUILDER
+*** FACTORY METHOD
+*** PROTOTYPE
+*** SINGLETON
+** STRUCTURAL PATTERNS
+*** ADAPTER OF CLASS
+*** ADAPTER OF OBJECT
+*** BRIDGE
+*** COMPOSITE
+*** DECORATOR
+*** FACADE
+*** FLYWEIGHT
+*** FLYWEIGHT + COMPOSITE
+*** PROXY
+** BEHAVIORAL PATTERNS
+*** CHAIN OF RESPONSIBILITY
+*** COMMAND
+*** INTERPRETER
+*** ITERATOR
+*** MEDIATOR
+*** MEMENTO
+*** OBSERVER
+*** STATE
+*** STRATEGY
+*** TEMPLATE METHOD
+*** VISITOR
+* ENTERPRISE PATTERNS
+** BUSINESS LOGIC
+*** DOMAIN MODEL
+*** SERVICE LAYER
+*** TRANSACTION SCRIPT
+*** TABLE MODULE
+** DATA SOURCES
+*** ACTIVE RECORD
+*** DATA MAPPER
+*** ROW DATA GATEWAY
+*** TABLE DATA GATEWAY
+** MODELING BEHAVIOR
+*** IDENTITY MAP
+*** LAZY LOAD
+*** UNIT OF WORK
+** MODELING STRUCTURE HIERARCHY
+*** CLASS TABLE INHERITANCE
+*** CONCRETE TABLE INHERITANCE
+*** INHERITANCE MAPPERS
+*** SINGLE TABLE INHERITANCE
+** MODELING STRUCTURE RELATIONS
+*** ASSOCIATION TABLE MAPPING
+*** DEPENDENT MAPPING
+*** EMBEDDED VALUE
+*** FOREIGN KEY MAPPING
+*** IDENTITY FIELD
+*** SERIALIZED LOB
+** METADATA
+*** METADATA MAPPING
+*** QUERY OBJECT
+*** REPOSITORY
+** WEB REPRESENTATION CONTROLLER
+*** MODEL VIEW CONTROLLER
+*** APPLICATION CONTROLLER
+*** FRONT CONTROLLER
+*** PAGE CONTROLLER
+** WEB REPRESENTATION VIEW
+*** TEMPLATE VIEW
+*** TRANSFORM VIEW
+*** TWO STEP VIEW
+** DISTRIBUTED PROCESSING
+*** DATA TRANSFER OBJECT
+*** REMOTE FAÇADE
+** PARALLEL PROCESSING
+*** COARSE-GRAINED LOCK
+*** IMPLICIT LOCK
+*** OPTIMISTIC OFFLINE LOCK
+*** PESSIMISTIC OFFLINE LOCK
+** SESSION STATE
+*** CLIENT SESSION STATE
+*** DATABASE SESSION STATE
+*** SERVER SESSION STATE
+** COMMON PATTERNS
+*** GATEWAY
+*** LAYER SUPERTYPE
+*** MAPPER
+*** MONEY
+*** PLUGIN
+*** RECORD SET
+*** REGISTRY
+*** SEPARATED INTERFACE
+*** SERVICE STUB
+*** SPECIAL CASE
+*** VALUE OBJECT
+* ANALYSIS PATTERNS
+** ACCOUNTABILITY
+*** PARTY
+*** ACCOUNTABILITY
+*** ORGANIZATION HIERARCHIES
+*** ORGANIZATION STRUCTURE
+*** ACCOUNTABILITY KNOWLEDGE LEVEL
+*** PARTY TYPE GENERALIZATIONS
+*** HIERARCHIC ACCOUNTABILITY
+*** OPERATING SCOPES
+*** POST
+** OBSERVATIONS AND MEASUREMENTS
+*** QUANTITY
+*** CONVERSION RATIO
+*** OBSERVATIONS AND MEASUREMENTS
+*** COMPOUND UNITS
+*** MEASUREMENT
+*** OBSERVATION
+*** SUBTYPING OBSERVATION CONCEPTS
+*** PROTOCOL
+*** DUAL TIME RECORD
+*** REJECTED OBSERVATION
+*** ACTIVE OBSERVATION, HYPOTHESIS, AND PROJECTION
+*** ASSOCIATED OBSERVATION
+*** PROCESS OF OBSERVATION
+** OBSERVATIONS FOR CORPORATE FINANCE
+*** ENTERPRISE SEGMENT
+*** MEASUREMENT PROTOCOL
+*** RANGE
+*** OBSERVATIONS FOR CORPORATE FINANCE
+*** PHENOMENON WITH RANGE
+*** REFERRING TO OBJECTS
+*** NAME
+*** IDENTIFICATION SCHEME
+*** OBJECT MERGE
+*** OBJECT EQUIVALENCE
+** REFERRING TO OBJECTS
+*** INVENTORY AND ACCOUNTING
+*** ACCOUNT
+*** TRANSACTIONS
+*** SUMMARY ACCOUNT
+*** MEMO ACCOUNT
+*** POSTING RULES
+** INVENTORY AND ACCOUNTING
+*** INDIVIDUAL INSTANCE METHOD
+*** POSTING RULE EXECUTION
+*** POSTING RULES FOR MANY ACCOUNTS
+*** CHOOSING ENTRIES
+*** ACCOUNTING PRACTICE
+*** SOURCES OF AN ENTRY
+*** BALANCE SHEET AND INCOME STATEMENT
+*** CORRESPONDING ACCOUNT
+*** SPECIALIZED ACCOUNT MODEL (BILLING EXAMPLE)
+*** SPECIALIZED ACCOUNT MODEL (INVENTORY EXAMPLE)
+*** BOOKING ENTRIES TO MULTIPLE ACCOUNTS
+** PLANNING
+*** PROPOSED AND IMPLEMENTED ACTION
+*** COMPLETED AND ABANDONED ACTIONS
+*** SUSPENSION
+*** PLAN
+*** PROTOCOL
+*** RESOURCE ALLOCATION
+*** PLANNING
+*** PLANNING (NO OUTCOME)
+*** OUTCOME AND START FUNCTIONS
+** TRADING
+*** CONTRACT
+*** PORTFOLIO
+*** QUOTE
+*** SCENARIO
+*** TRADING
+** DERIVATIVE CONTRACTS
+*** FORWARD CONTRACTS
+*** OPTIONS
+*** PRODUCT
+*** SUBTYPE STATE MACHINES
+*** PARALLEL APPLICATION AND DOMAIN HIERARCHIES
+*** DERIVATIVE CONTRACTS
+** TRADING PACKAGES
+*** MULTIPLE ACCESS LEVELS TO A PACKAGE
+*** MUTUAL VISIBILITY
+*** TRADING PACKAGES
+** LAYERED ARCHITECTURE FOR INFORMATION SYSTEMS
+*** TWO-TIER ARCHITECTURE
+*** THREE-TIER ARCHITECTURE
+*** PRESENTATION AND APPLICATION LOGIC
+*** DATABASE INTERACTION
+** TYPE MODEL DESIGN
+*** IMPLEMENTING ASSOCIATIONS
+*** IMPLEMENTING GENERALIZATION
+*** OBJECT CREATION
+*** OBJECT DESTRUCTION
+*** ENTRY POINT.
+*** IMPLEMENTING CONSTRAINTS
+* DOMAIN DRIVEN DESIGN
+** MODEL AND STRUCTURAL ELEMENTS
+*** MODEL-DRIVEN DESIGN
+*** LAYERED ARCHITECTURE (ASYMMETRIC )
+*** HEXAGONAL ARCHITECTURE (SYMMETRIC)
+*** COMPOSITE UI
+*** ENTITIES
+*** VALUE-OBJECTS
+*** DOMAIN SERVICES
+*** MODULES
+*** AGGREGATES
+*** AGGREGATE ROOT
+*** BEHAVIOR‐FOCUSED AGGREGATE ROOT
+*** MODIFY AND COMMIT ONLY ONE AGGREGATE INSTANCE IN ONE TRANSACTION
+*** PROTECT BUSINESS INVARIANTS INSIDE AGGREGATE BOUNDARIES
+*** REFERENCE OTHER AGGREGATES BY IDENTITY ONLY
+*** FACTORIES
+*** REPOSITORIES
+** SUPPLE DESIGN
+*** UBIQUITOUS LANGUAGE
+*** INTENTION-REVEALING INTERFACES
+*** SIDE-EFFECT FREE FUNCTIONS
+*** ASSERTIONS
+*** CONCEPTUAL CONTOURS
+*** STANDALONE CLASSES
+*** CLOSURE OF OPERATIONS
+** MODEL INTEGRITY AND CONTEXT
+*** BOUNDED CONTEXT
+*** CONTINUOUS INTEGRATION
+*** STRATEGIC CONTEXT MAP
+*** CONTEXTUAL MAP
+*** SHARED KERNEL
+*** CUSTOMER-SUPPLIER TEAMS
+*** CONFORMIST
+*** ANTICORRUPTION LAYER
+*** SEPARATE WAYS
+*** OPEN HOST SERVICE
+*** PUBLISHED LANGUAGE
+** DISTILLATION
+*** CORE DOMAIN
+*** GENERIC SUBDOMAINS
+*** DOMAIN VISION STATEMENT
+*** HIGHLIGHTED CORE
+*** COHESIVE MECHANISMS
+*** SEGREGATED CORE
+*** ABSTRACT CORE
+** LARGE-SCALE STRUCTURE
+*** EVOLVING ORDER
+*** SYSTEM METAPHOR
+*** RESPONSIBILITY LAYERS
+*** KNOWLEDGE LEVEL
+*** PLUGGABLE COMPONENT FRAMEWORK
+** ADDITIONAL PATTERNS
+*** TYPES OF CONSISTENCY
+*** EVENT SOURCING
+*** EVENT PROCESSOR
+*** EVENT DISPATCHER
+*** INTERNAL DOMAIN EVENTS
+*** EXTERNAL DOMAIN EVENTS, TRANSFER BETWEEN CONTEXTS
+*** STATIC DOMAIN EVENTS CLASS
+*** ONE SUBDOMAIN PER BOUNDED CONTEXT
+*** THE APPLICATION LAYER COORDINATES THE WORK BETWEEN CONTEXTS
+*** THE SAME PHYSICAL ENTITY IN DIFFERENT CONTEXTS
+*** INTEGRATION OF BOUDED CONTEXTS THROUGH DATABASE
+*** INTEGRATION OF BOUDED CONTEXTS THROUGH FLAT FILES
+*** INTEGRATION OF BOUDED CONTEXTS THROUGH ENTERPRISE SERVICE BUS
+*** INTEGRATION OF BOUDED CONTEXTS THROUGH MESSAGE QUEUE
+*** DEPENDENCY INJECTION
+*** DEPENDENCY INVERSION
+*** INVERSION OF CONTROL
+*** SERVICE LOCATOR
+*** CQRS
+*** CQS
+*** WRAP LOW-LEVEL EXCEPTIONS
+*** EXTRACT DEPENDENCY FROM INTERFACE TO COSNTRUCTOR
+*** INTERFACE SEGREGATION
+** CLEAN ARCHITECTURE
+
+
+== Architecture with JArchitect
+image:https://www.jarchitect.com/assets/img/transparentlogo.png["JArchitecture",width=170,link="http://www.jarchitect.com"]
+Architecture diagrams is also presented for comparison (coming soon!), built with JArchitect. Thanks to Codegears / CppDepend for the JArchitect.
+
+== Architecture with Structure101
+image:http://structure101.com/images/s101_170.png["Structure101",width=170,link="http://www.Structure101.com"]
+Architecture diagrams is also presented for comparison, built with Structure101 Studio. Thanks to Structure101 for the Studio/Workspace.
diff --git a/README.md b/README.md
deleted file mode 100644
index 16887f3..0000000
--- a/README.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# patterns
-Complete catalog of all classical patterns in the Archimate language (ArchiTool used https://www.archimatetool.com)
-This version includes all 155+ patterns completed (278+ models). Images also available.
-
-- Domain driven design patterns
-- Fowler's Analysis patterns
-- Fowler's Enterprise patterns
-- GoF classical Design patterns
-
-It's great opportunity to use best practices in your micro service architecture
-Also avialable at http://arch.expert.life/en/patterns
-
-See huge examples inside
-
-
-
-
\ No newline at end of file
diff --git a/design patterns catalog/A Creational patterns/1 Abstract Factory v1.archimate b/design patterns catalog/A Creational patterns/1 Abstract Factory v1.archimate
index db2cd44..d623259 100644
--- a/design patterns catalog/A Creational patterns/1 Abstract Factory v1.archimate
+++ b/design patterns catalog/A Creational patterns/1 Abstract Factory v1.archimate
@@ -1,238 +1,548 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- и получаем интерфейс
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- работаю с набором продуктов через интерфейсы продуктов
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- select product group 1 or group 2
-(for example select A)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ и получаем интерфейс
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ и получаем интерфейс
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ и получаем интерфейс
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ работаю с набором продуктов через интерфейсы продуктов
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ работаю с набором продуктов через интерфейсы продуктов
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ работаю с набором продуктов через интерфейсы продуктов
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select product group 1 or group 2
+(for example select A)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ In the whole program (except for the factory inside and one factory creation) we work only with interfaces (and do not refer to specific classes)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ When you start the program in the main method, create all factories - this isolates the creation of all specific dependencies in one place
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select product group 1 or group 2
+(for example select A)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Depends on string "A" or "B" method creates A1 or B1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Depends on string "A" or "B" method creates A2 or B2
+
+
+
+
+
+ when you add a new product class, the interface remains unchanged (that is, no new methods are added to it) and you do not need to recompile any classes that depend on that interface
+
+
+
+ when a new product class is added, the change is made only to the factory implementation. The solution is potentially dangerous because an error in writing the class name (string argument passed to the input of the function) will lead to a runtime error
+
+
+
+
diff --git a/design patterns catalog/A Creational patterns/1 Abstract Factory v1.archimate.bak b/design patterns catalog/A Creational patterns/1 Abstract Factory v1.archimate.bak
new file mode 100644
index 0000000..a266956
--- /dev/null
+++ b/design patterns catalog/A Creational patterns/1 Abstract Factory v1.archimate.bak
@@ -0,0 +1,492 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ и получаем интерфейс
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ и получаем интерфейс
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ и получаем интерфейс
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ работаю с набором продуктов через интерфейсы продуктов
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ работаю с набором продуктов через интерфейсы продуктов
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ работаю с набором продуктов через интерфейсы продуктов
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select product group 1 or group 2
+(for example select A)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ In the whole program (except for the factory inside and one factory creation) we work only with interfaces (and do not refer to specific classes)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ When you start the program in the main method, create all factories - this isolates the creation of all specific dependencies in one place
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select product group 1 or group 2
+(for example select A)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/design patterns catalog/B Structural patterns/2 Bridge v1.archimate b/design patterns catalog/B Structural patterns/2 Bridge v1.archimate
index 0b75b35..3ff6829 100644
--- a/design patterns catalog/B Structural patterns/2 Bridge v1.archimate
+++ b/design patterns catalog/B Structural patterns/2 Bridge v1.archimate
@@ -1,377 +1,778 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- method call through the two inheritance hierarchy and a link between the hierarchies
-- for example, call some methods of the class A
-- wich leads to invoke methods of the class C
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- imp->method 3
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ method call through the two inheritance hierarchy and a link between the hierarchies
+- for example, call some methods of the class A
+- wich leads to invoke methods of the class C
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ imp->method 3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - this pattern is like simply delegating work to another class that has the same set of methods, but now we can independently modify these classes
+- without this pattern, we would directly work with the Car interface and its changes would directly affect clients
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Without a bridge pattern.
+It can be seen that you have to create a lot of implementations (the number of features is MULTIPLIED by the number of implementation options),
+much more than the bridge pattern (the number of features PLUS on the number of implementation options)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/design patterns catalog/B Structural patterns/5 Facade v1.archimate b/design patterns catalog/B Structural patterns/5 Facade v1.archimate
index 526cd50..f4c7544 100644
--- a/design patterns catalog/B Structural patterns/5 Facade v1.archimate
+++ b/design patterns catalog/B Structural patterns/5 Facade v1.archimate
@@ -1,137 +1,288 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- You can change the inner layer classes without fear affects other layers
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- facade created absolutly new interface
-- only one point (class/interface)
-- simplified (short)
-- default
-- common
-- for most frequent cases
-
-if I want use all possibilities, I use directly all classes
-
-one-way calls. facade sends requests subsystem classes
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ You can change the inner layer classes without fear affects other layers
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ facade created absolutly new interface
+- only one point (class/interface)
+- simplified (short)
+- default
+- common
+- for most frequent cases
+
+if I want use all possibilities, I use directly all classes
+
+one-way calls. facade sends requests subsystem classes
+
+
+
+
+ antipattern: if the facade is a class (not an interface) then all clients will transitively depend on all classes behind the facade
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ It is dangerous to create dependencies on modules that contain more than you need. The diagram shows that the interfaces are separated and changing one will not affect the client of the other interface
+
+
+
+ This pattern as a counterbalance to the facade pattern (which on the contrary may contain too many responsibilities)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/design patterns catalog/B Structural patterns/5 Facade v1.archimate.bak b/design patterns catalog/B Structural patterns/5 Facade v1.archimate.bak
new file mode 100644
index 0000000..2023e1e
--- /dev/null
+++ b/design patterns catalog/B Structural patterns/5 Facade v1.archimate.bak
@@ -0,0 +1,284 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ You can change the inner layer classes without fear affects other layers
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ facade created absolutly new interface
+- only one point (class/interface)
+- simplified (short)
+- default
+- common
+- for most frequent cases
+
+if I want use all possibilities, I use directly all classes
+
+one-way calls. facade sends requests subsystem classes
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ It is dangerous to create dependencies on modules that contain more than you need. The diagram shows that the interfaces are separated and changing one will not affect the client of the other interface
+
+
+
+ This pattern as a counterbalance to the facade pattern (which on the contrary may contain too many responsibilities)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/design patterns catalog/C Behavioral patterns/10 Template Method v1.archimate b/design patterns catalog/C Behavioral patterns/10 Template Method v1.archimate
index aef38e8..0014b74 100644
--- a/design patterns catalog/C Behavioral patterns/10 Template Method v1.archimate
+++ b/design patterns catalog/C Behavioral patterns/10 Template Method v1.archimate
@@ -1,228 +1,593 @@
-
-
-
-
-
-
- -распорядитель
--парсит один объект и собирает на его основе другой объект
-
-
-
- здесь может быть парсер, разбирающий одно какое либо дерево и получающий с одним и тем же алгоритмом разные выходные объекты
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- select: A or B
-(for example A)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- The method which is fully realized in terms of other methods
-
-
-
-
-
-
-
-
-
- ..
-method 1 ( )
-..
-method 2 ( )
-..
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- алгоритм работы зашит в отдельном классе
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+ -распорядитель
+-парсит один объект и собирает на его основе другой объект
+
+
+
+ здесь может быть парсер, разбирающий одно какое либо дерево и получающий с одним и тем же алгоритмом разные выходные объекты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ здесь может быть парсер, разбирающий одно какое либо дерево и получающий с одним и тем же алгоритмом разные выходные объекты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ здесь может быть парсер, разбирающий одно какое либо дерево и получающий с одним и тем же алгоритмом разные выходные объекты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ здесь может быть парсер, разбирающий одно какое либо дерево и получающий с одним и тем же алгоритмом разные выходные объекты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select: A or B
+(for example A)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The method which is fully realized in terms of other methods
+
+
+
+
+
+
+
+
+
+ ..
+method 1 ( )
+..
+method 2 ( )
+..
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ алгоритм работы зашит в отдельном классе
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select: A or B
+(for example A)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The method which is fully realized in terms of other methods
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ this abstract class can be reused for different algorithms requiring the same steps
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ difference between template method and strategy patterns
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select: A or B
+(for example A)
+
+
+
+ Varian1) template method
+
+
+
+ Varian2) strategy
+
+
+
+ Varian3) lambdas as input parameters
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/design patterns catalog/C Behavioral patterns/10 Template Method v1.archimate.bak b/design patterns catalog/C Behavioral patterns/10 Template Method v1.archimate.bak
new file mode 100644
index 0000000..1ecabbe
--- /dev/null
+++ b/design patterns catalog/C Behavioral patterns/10 Template Method v1.archimate.bak
@@ -0,0 +1,593 @@
+
+
+
+
+
+
+ -распорядитель
+-парсит один объект и собирает на его основе другой объект
+
+
+
+ здесь может быть парсер, разбирающий одно какое либо дерево и получающий с одним и тем же алгоритмом разные выходные объекты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ здесь может быть парсер, разбирающий одно какое либо дерево и получающий с одним и тем же алгоритмом разные выходные объекты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ здесь может быть парсер, разбирающий одно какое либо дерево и получающий с одним и тем же алгоритмом разные выходные объекты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ здесь может быть парсер, разбирающий одно какое либо дерево и получающий с одним и тем же алгоритмом разные выходные объекты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select: A or B
+(for example A)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The method which is fully realized in terms of other methods
+
+
+
+
+
+
+
+
+
+ ..
+method 1 ( )
+..
+method 2 ( )
+..
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ алгоритм работы зашит в отдельном классе
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select: A or B
+(for example A)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The method which is fully realized in terms of other methods
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ this abstract class can be reused for different algorithms requiring the same steps
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ difference between template method and strategy patterns
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ select: A or B
+(for example A)
+
+
+
+ Varian1) template method
+
+
+
+ Varian2) strategy
+
+
+
+ Varian3) lambdas as input parameters
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/design patterns catalog/C Behavioral patterns/11 Visitor v1.archimate b/design patterns catalog/C Behavioral patterns/11 Visitor v1.archimate
index 5fe0704..eaeb567 100644
--- a/design patterns catalog/C Behavioral patterns/11 Visitor v1.archimate
+++ b/design patterns catalog/C Behavioral patterns/11 Visitor v1.archimate
@@ -1,421 +1,1119 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- The new operation is created by adding a subclass
-Visitors to the hierarchy of classes
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- the visitor can visit the objects/classes of ANY types
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- VISITOR -> visit Concrete Element A (this)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- VISITOR -> visit Concrete Element B (this)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The general purpose of the pattern Visitor: add a new method to the class. But I do not directly add the new method to the class, instead I create a method that accepts any visitor (i.e. any additional code)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ the visitor can visit the objects/classes of ANY types
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The new operation is created by adding a visitor-subclass to the hierarchy of visitor classes
+
+
+
+ compared to the previous illustration, this is simply a different arrangement of elements, so that you can compare it to the acyclic visitor and the object-extension pattern
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ VISITOR -> visit Concrete Element A (this)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ VISITOR -> visit Concrete Element B (this)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ when adding a new class to the hierarchy A, B .., now there is no need to change the basic visitor interface (and also no need to recompile all classes dependent on it)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ marker interface without methods inside
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The new operation is created by adding a visitor-subclass to the hierarchy of visitor classes
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Acyclic visitor pattern
+
+
+
+
+
+ when adding a new class to the hierarchy A, B .., now there is no need to change the basic visitor interface (and also no need to recompile all classes dependent on it)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ marker interface without methods inside
+
+
+
+
+
+
+
+
+
+
+
+ the constructor sets the property by reference to the object of type A passed to it as input
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ string contains name of the visitor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ the interface contains methods specific to this feature (extension), which is represented by this interface
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Extension object pattern
+(for explanation you can imagine extension as visitor)
+
+
+
+ - the user must remember the association of the text name with the type of visitor
+- for example: VisitorTXT v=(VisitorTXT)objectOfClassA.getVisitor("txt")
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/domain driven design patterns/A Model and structural elements/1 model-driven design.archimate b/domain driven design patterns/A Model and structural elements/1 model-driven design.archimate
index 1075094..79cd3f3 100644
--- a/domain driven design patterns/A Model and structural elements/1 model-driven design.archimate
+++ b/domain driven design patterns/A Model and structural elements/1 model-driven design.archimate
@@ -1,142 +1,187 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- усовершенствование модели, проектирование и реализация идут параллельно в итерационном процессе разработки программы
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- layers - TOGAF's architecture domains
-
-
-
-
-
- model driven design
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ усовершенствование модели, проектирование и реализация идут параллельно в итерационном процессе разработки программы
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ layers - TOGAF's architecture domains
+
+
+
+
+
+ model driven design
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ If we go to the cause of class changes - those to the business customer, it turns out that each class is associated with one such 'person'. This is due to Conway’s law that the structure of the program reflects the structure of the organization.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Single responsibility principle from the SOLID model
+
+
+
+
diff --git a/domain driven design patterns/A Model and structural elements/1 model-driven design.archimate.bak b/domain driven design patterns/A Model and structural elements/1 model-driven design.archimate.bak
new file mode 100644
index 0000000..0933863
--- /dev/null
+++ b/domain driven design patterns/A Model and structural elements/1 model-driven design.archimate.bak
@@ -0,0 +1,195 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ усовершенствование модели, проектирование и реализация идут параллельно в итерационном процессе разработки программы
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ layers - TOGAF's architecture domains
+
+
+
+
+
+ model driven design
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ model driven design
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/domain driven design patterns/A Model and structural elements/10 repositories.archimate b/domain driven design patterns/A Model and structural elements/10 repositories.archimate
index 9c753ff..3faed6e 100644
--- a/domain driven design patterns/A Model and structural elements/10 repositories.archimate
+++ b/domain driven design patterns/A Model and structural elements/10 repositories.archimate
@@ -1,408 +1,674 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- АГРЕГАТЫ обозначают область действия, в пределах которой на каждом этапе жизненного цикла должны удовлетворяться определенные инварианты
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- domain layer
-
-
-
- application service layer
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- In practice, the repository should not have all the CRUD methods (or methods like FindBy(any query) ) and should not be inherited from the common interface.
-The repository must be specific to your aggregate and contain only methods specific to your domain
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - Use repository to persist and to retrieve aggregates.
-- Repository is a virtual emulating set of aggregates
-- The collection gives the illusion that objects are stored in memory
-- For example, there can be no array, the objects are serialized / deserialized from the database
-- For example, it exposes the interface of an in-memory collection of aggregate roots
-
-GoF pattern: facade
-Fouler's pattern: repository
-
-
-
-
-
-
-
-
-
-
- After extracting aggregate data from the database, it is necessary to create an aggregate in memory
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- The internal objects of the aggregate can be found through the root
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- GoF pattern: memento
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- The version attribute is not a domain attribute
-
-
-
-
- Fowler's patters: optimistic lock
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ АГРЕГАТЫ обозначают область действия, в пределах которой на каждом этапе жизненного цикла должны удовлетворяться определенные инварианты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ domain layer
+
+
+
+ application service layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ In practice, the repository should not have all the CRUD methods (or methods like FindBy(any query) ) and should not be inherited from the common interface.
+The repository must be specific to your aggregate and contain only methods specific to your domain
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - Use repository to persist and to retrieve aggregates.
+- Repository is a virtual emulating set of aggregates
+- The collection gives the illusion that objects are stored in memory
+- For example, there can be no array, the objects are serialized / deserialized from the database
+- For example, it exposes the interface of an in-memory collection of aggregate roots
+
+GoF pattern: facade
+Fouler's pattern: repository
+
+
+
+
+
+
+
+
+
+
+ After extracting aggregate data from the database, it is necessary to create an aggregate in memory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The internal objects of the aggregate can be found through the root
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ GoF pattern: memento
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The version attribute is not a domain attribute
+
+
+
+
+ Fowler's patters: optimistic lock
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ exception if not found
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ @Repository("bookingRepository")
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ It's seens that the method the same (as in repository) but acording with Bridge Pattern, now I can change it seperately
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ @Service("bookingService")
+
+
+
+
+
+ also Bridge Pattern: abstract class has a reference to Repository interface
+
+
+
+ Bridge Pattern: abstract class has a reference to Repository interface
+
+
+
+
+
diff --git a/domain driven design patterns/A Model and structural elements/10 repositories.archimate.bak b/domain driven design patterns/A Model and structural elements/10 repositories.archimate.bak
new file mode 100644
index 0000000..39960ef
--- /dev/null
+++ b/domain driven design patterns/A Model and structural elements/10 repositories.archimate.bak
@@ -0,0 +1,674 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ АГРЕГАТЫ обозначают область действия, в пределах которой на каждом этапе жизненного цикла должны удовлетворяться определенные инварианты
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ domain layer
+
+
+
+ application service layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ In practice, the repository should not have all the CRUD methods (or methods like FindBy(any query) ) and should not be inherited from the common interface.
+The repository must be specific to your aggregate and contain only methods specific to your domain
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - Use repository to persist and to retrieve aggregates.
+- Repository is a virtual emulating set of aggregates
+- The collection gives the illusion that objects are stored in memory
+- For example, there can be no array, the objects are serialized / deserialized from the database
+- For example, it exposes the interface of an in-memory collection of aggregate roots
+
+GoF pattern: facade
+Fouler's pattern: repository
+
+
+
+
+
+
+
+
+
+
+ After extracting aggregate data from the database, it is necessary to create an aggregate in memory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The internal objects of the aggregate can be found through the root
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ GoF pattern: memento
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The version attribute is not a domain attribute
+
+
+
+
+ Fowler's patters: optimistic lock
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ exception if not found
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ @Repository("bookingRepository")
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ вроде бы те же самые методы но на самом деле я теперь могу их менять отдельно от repository
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ @Service("bookingService")
+
+
+
+
+
+ паттерн мост: абстрактный класс содержит интерфейс
+
+
+
+ паттерн мост: абстрактный класс содержит интерфейс
+
+
+
+
+
diff --git a/domain driven design patterns/A Model and structural elements/2 layered architecture.archimate b/domain driven design patterns/A Model and structural elements/2 layered architecture.archimate
index cde7fa6..e239361 100644
--- a/domain driven design patterns/A Model and structural elements/2 layered architecture.archimate
+++ b/domain driven design patterns/A Model and structural elements/2 layered architecture.archimate
@@ -1,305 +1,1061 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Отвечает за вывод информации пользователю и интерпретирование его команд. Внешним действующим субъектом
-может быть не человек, а другая компьютерная система
-
-
- Application Services Represent Use Cases, not CRUD
-
-Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
-области. Задания, выполняемые этим уровнем, имеют смысл
-для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
-Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
-а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
-содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
-
-
- Отвечает за представление понятий прикладной предметной
-области, рабочие состояния, деловые регламенты. Именно
-здесь контролируется и используется текущее состояние
-прикладной модели, пусть даже технические подробности
-манипуляций данными делеГИРУIОТСЯ инфраструктуре.
-Этот уровень является главной, алгоритмической частью
-nрограммы
-
-
- Обеспечивает непосредственную техническую поддержку
-для верхних уровней: передачу сооБIl�ений на операционном
-уровне, непрерывность существования объектов на уровне
-модели, вывод элементов управления на уровне пользовательского интерфейса и т.д. Инфраструктурный уровень
-может также брать на себя поддержку схемы взаимосвязей
-между четырьмя уровнями через архитектурную среду приложения
-
-
-
- Application Services that orchestrate use cases
-and manage transactions;
-
-
- Input Adapters , such as user interface
-controllers, REST endpoints, and message listeners;
-
-
- Hexagonal
-Architecture (also known as the Ports and
-Adapters Architecture), and the Onion
-Architecture
-
-
-
-
-
- Output Adapters such
-as persistence management and message senders.
-
-
- Application Services that orchestrate use cases
-and manage transactions;
-
-
- Application Services that orchestrate use cases
-and manage transactions;
-
-
- Application Services that orchestrate use cases
-and manage transactions;
-
-
- Application Services that orchestrate use cases
-and manage transactions;
-
-
- Application Services that orchestrate use cases
-and manage transactions;
-
-
- Input Adapters , such as user interface
-controllers, REST endpoints, and message listeners;
-
-
- Input Adapters , such as user interface
-controllers, REST endpoints, and message listeners;
-
-
- Input Adapters , such as user interface
-controllers, REST endpoints, and message listeners;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- layered architecture
-Only domain layer is required
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Objects of the domain should be clearly separated/isolated from other functions of the system
-
-
-
-
-
-
-
-
-
- infrastructure / presentation layer
-
-
-
- application service layer
-
-
-
- domain layer
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Hexagonal Architecture
-Ports and Adapters Architecture
-Onion Architecture
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Unlike the layer architecture, there is no difference between the infrastructural and presentation layers (both are symmetrically located around the service layer)
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Отвечает за вывод информации пользователю и интерпретирование его команд. Внешним действующим субъектом
+может быть не человек, а другая компьютерная система
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Обеспечивает непосредственную техническую поддержку
+для верхних уровней: передачу сооБIl�ений на операционном
+уровне, непрерывность существования объектов на уровне
+модели, вывод элементов управления на уровне пользовательского интерфейса и т.д. Инфраструктурный уровень
+может также брать на себя поддержку схемы взаимосвязей
+между четырьмя уровнями через архитектурную среду приложения
+
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Hexagonal
+Architecture (also known as the Ports and
+Adapters Architecture), and the Onion
+Architecture
+
+
+
+
+
+ Output Adapters such
+as persistence management and message senders.
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Отвечает за вывод информации пользователю и интерпретирование его команд. Внешним действующим субъектом
+может быть не человек, а другая компьютерная система
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Обеспечивает непосредственную техническую поддержку
+для верхних уровней: передачу сооБIl�ений на операционном
+уровне, непрерывность существования объектов на уровне
+модели, вывод элементов управления на уровне пользовательского интерфейса и т.д. Инфраструктурный уровень
+может также брать на себя поддержку схемы взаимосвязей
+между четырьмя уровнями через архитектурную среду приложения
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Output Adapters such
+as persistence management and message senders.
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Output Adapters such
+as persistence management and message senders.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ layered architecture
+Only domain layer is required
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Objects of the domain should be clearly separated/isolated from other functions of the system
+
+
+
+
+
+
+
+
+
+ infrastructure / presentation layer
+
+
+
+ application service layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Hexagonal Architecture
+Ports and Adapters Architecture
+Onion Architecture
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Unlike the layer architecture, there is no difference between the infrastructural and presentation layers (both are symmetrically located around the service layer)
+
+
+
+
+
+
+
+
+
+
+ The more towards the center the more important the level. The level depends only on an even more important level with which it is connected internally and is independent of the external.
+
+
+
+
+
+ Types of connections in layered architecture. Note that despite the fact that all types of connections are different, they still go in the same direction. And the upper level (for example, the most important domain level) does not depend on the implementation of the lower levels. Open-closed principle from the SOLID model.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ lower level classes implement upper level interfaces.
+see patterns: Separated Interface, Dependency Inversion
+
+
+
+ The lower-level classes do not call the upper-level classes directly, but through a protective interface (which hides the features of the main-level implementation)
+
+
+
+ lower levels freely use DTO, Value-objects defined on the upper level
+
+
+
+ for example, the main level can connect the lower level through automatic linking of the connected plug-in (see pattern plug-in)
+
+
+
+ variant 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ variant 2
+
+
+
+
+
+
+
+
+
+
+
+
+ interfaces and value objects for data exchange are placed in a separate level. Both domain and service level depend on the intermediate level (for example separate package in Java or different namespace in C++)
+
+
+
+
+
+ application service layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ lower level classes implement upper level interfaces.
+see patterns: Separated Interface, Dependency Inversion
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ it is shown how to receive calls from dependent modules and transfer calls to dependent modules
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The lower-level classes do not call the upper-level classes directly, but through a protective interface (which hides the features of the main-level implementation)
+
+
+
+
+
+
+
+
+
+
+
+ lower levels freely use DTO, Value-objects defined on the upper level
+
+
+
+
+
+
+
+
+
+
+ application service layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ the high-level component itself actively controls the interaction of low-level components. In this case, the logical flow of data (information from the input adapter to the receiver) and dependencies(the receiver actively polls the adapter itself) in opposite directions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ lower level classes implement upper level interfaces.
+see patterns: Separated Interface, Dependency Inversion
+
+
+
+
+
+ infrastructure / presentation layer
+
+
+
+ application service layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ the direction of all dependencies (inheritance or challenges) is strictly towards the center, there are no other directions and there are absolutely no cyclic dependencies
+
+
+
+
diff --git a/domain driven design patterns/A Model and structural elements/2 layered architecture.archimate.bak b/domain driven design patterns/A Model and structural elements/2 layered architecture.archimate.bak
new file mode 100644
index 0000000..e02d5a5
--- /dev/null
+++ b/domain driven design patterns/A Model and structural elements/2 layered architecture.archimate.bak
@@ -0,0 +1,1061 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Отвечает за вывод информации пользователю и интерпретирование его команд. Внешним действующим субъектом
+может быть не человек, а другая компьютерная система
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Обеспечивает непосредственную техническую поддержку
+для верхних уровней: передачу сооБIl�ений на операционном
+уровне, непрерывность существования объектов на уровне
+модели, вывод элементов управления на уровне пользовательского интерфейса и т.д. Инфраструктурный уровень
+может также брать на себя поддержку схемы взаимосвязей
+между четырьмя уровнями через архитектурную среду приложения
+
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Hexagonal
+Architecture (also known as the Ports and
+Adapters Architecture), and the Onion
+Architecture
+
+
+
+
+
+ Output Adapters such
+as persistence management and message senders.
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Отвечает за вывод информации пользователю и интерпретирование его команд. Внешним действующим субъектом
+может быть не человек, а другая компьютерная система
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Обеспечивает непосредственную техническую поддержку
+для верхних уровней: передачу сооБIl�ений на операционном
+уровне, непрерывность существования объектов на уровне
+модели, вывод элементов управления на уровне пользовательского интерфейса и т.д. Инфраструктурный уровень
+может также брать на себя поддержку схемы взаимосвязей
+между четырьмя уровнями через архитектурную среду приложения
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Output Adapters such
+as persistence management and message senders.
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Application Services that orchestrate use cases
+and manage transactions;
+
+
+ Input Adapters , such as user interface
+controllers, REST endpoints, and message listeners;
+
+
+ Output Adapters such
+as persistence management and message senders.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ layered architecture
+Only domain layer is required
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Objects of the domain should be clearly separated/isolated from other functions of the system
+
+
+
+
+
+
+
+
+
+ infrastructure / presentation layer
+
+
+
+ application service layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Hexagonal Architecture
+Ports and Adapters Architecture
+Onion Architecture
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Unlike the layer architecture, there is no difference between the infrastructural and presentation layers (both are symmetrically located around the service layer)
+
+
+
+
+
+
+
+
+
+
+ The more towards the center the more important the level. The level depends only on an even more important level with which it is connected internally and is independent of the external.
+
+
+
+
+
+ Types of connections in layered architecture. Note that despite the fact that all types of connections are different, they still go in the same direction. And the upper level (for example, the most important domain level) does not depend on the implementation of the lower levels. Open-closed principle from the SOLID model.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ lower level classes implement upper level interfaces.
+see patterns: Separated Interface, Dependency Inversion
+
+
+
+ The lower-level classes do not call the upper-level classes directly, but through a protective interface (which hides the features of the main-level implementation)
+
+
+
+ lower levels freely use DTO, Value-objects defined on the upper level
+
+
+
+ for example, the main level can connect the lower level through automatic linking of the connected plug-in (see pattern plug-in)
+
+
+
+ variant 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ variant 2
+
+
+
+
+
+
+
+
+
+
+
+
+ interfaces and value objects for data exchange are placed in a separate level. Both domain and service level depend on the intermediate level
+
+
+
+
+
+ application service layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ lower level classes implement upper level interfaces.
+see patterns: Separated Interface, Dependency Inversion
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ it is shown how to receive calls from dependent modules and transfer calls to dependent modules
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The lower-level classes do not call the upper-level classes directly, but through a protective interface (which hides the features of the main-level implementation)
+
+
+
+
+
+
+
+
+
+
+
+ lower levels freely use DTO, Value-objects defined on the upper level
+
+
+
+
+
+
+
+
+
+
+ application service layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ the high-level component itself actively controls the interaction of low-level components. In this case, the logical flow of data (information from the input adapter to the receiver) and dependencies(the receiver actively polls the adapter itself) in opposite directions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ lower level classes implement upper level interfaces.
+see patterns: Separated Interface, Dependency Inversion
+
+
+
+
+
+ infrastructure / presentation layer
+
+
+
+ application service layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ the direction of all dependencies (inheritance or challenges) is strictly towards the center, there are no other directions and there are absolutely no cyclic dependencies
+
+
+
+
diff --git a/domain driven design patterns/A Model and structural elements/6 domain services.archimate b/domain driven design patterns/A Model and structural elements/6 domain services.archimate
index bab39fb..58a53f5 100644
--- a/domain driven design patterns/A Model and structural elements/6 domain services.archimate
+++ b/domain driven design patterns/A Model and structural elements/6 domain services.archimate
@@ -1,335 +1,499 @@
-
-
-
-
-
-
-
-
-
-
- A business service represents an explicitly defined exposed business behavior
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- An application service represents an explicitly defined exposed application behavior
-
-
- An application service represents an explicitly defined exposed application behavior
-
-
-
-
-
-
-
-
-
-
- A technology service represents an explicitly defined exposed technology behavior.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Отвечает за вывод информации пользователю и интерпретирование его команд. Внешним действующим субъектом
-может быть не человек, а другая компьютерная система
-
-
- Application Services Represent Use Cases, not CRUD
-
-Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
-области. Задания, выполняемые этим уровнем, имеют смысл
-для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
-Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
-а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
-содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
-
-
- Отвечает за представление понятий прикладной предметной
-области, рабочие состояния, деловые регламенты. Именно
-здесь контролируется и используется текущее состояние
-прикладной модели, пусть даже технические подробности
-манипуляций данными делеГИРУIОТСЯ инфраструктуре.
-Этот уровень является главной, алгоритмической частью
-nрограммы
-
-
- Обеспечивает непосредственную техническую поддержку
-для верхних уровней: передачу сооБIl�ений на операционном
-уровне, непрерывность существования объектов на уровне
-модели, вывод элементов управления на уровне пользовательского интерфейса и т.д. Инфраструктурный уровень
-может также брать на себя поддержку схемы взаимосвязей
-между четырьмя уровнями через архитектурную среду приложения
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- their responsibility is to orchestrate (but don’t actually implement it) BUSINESS logic using entities and value objects
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Example of communicating services with aggregates via direct service call
-
-
-
-
-
-
- application service layer
-
-
-
- infrastructure layer
-
-
-
- domain layer
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Services support each other
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Example of communicating services with aggregates through events
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+ A business service represents an explicitly defined exposed business behavior
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ An application service represents an explicitly defined exposed application behavior
+
+
+ An application service represents an explicitly defined exposed application behavior
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A technology service represents an explicitly defined exposed technology behavior.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Отвечает за вывод информации пользователю и интерпретирование его команд. Внешним действующим субъектом
+может быть не человек, а другая компьютерная система
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Обеспечивает непосредственную техническую поддержку
+для верхних уровней: передачу сооБIl�ений на операционном
+уровне, непрерывность существования объектов на уровне
+модели, вывод элементов управления на уровне пользовательского интерфейса и т.д. Инфраструктурный уровень
+может также брать на себя поддержку схемы взаимосвязей
+между четырьмя уровнями через архитектурную среду приложения
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ their responsibility is to orchestrate (but don’t actually implement it) BUSINESS logic using entities and value objects
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Example of communicating services with aggregates via direct service call
+
+
+
+
+
+
+ application service layer
+
+
+
+ infrastructure layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Services support each other
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Example of communicating services with aggregates through events
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ my=repository.getMyById(id)
+
+my.do(amount)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MyService-MyServiceImpl and MyRepository-MyRepositoryImpl is a Bridge-pattern
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ wrap lower-level exceptions into service-level exceptions
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/domain driven design patterns/A Model and structural elements/6 domain services.archimate.bak b/domain driven design patterns/A Model and structural elements/6 domain services.archimate.bak
new file mode 100644
index 0000000..f02a98f
--- /dev/null
+++ b/domain driven design patterns/A Model and structural elements/6 domain services.archimate.bak
@@ -0,0 +1,517 @@
+
+
+
+
+
+
+
+
+
+
+ A business service represents an explicitly defined exposed business behavior
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ An application service represents an explicitly defined exposed application behavior
+
+
+ An application service represents an explicitly defined exposed application behavior
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A technology service represents an explicitly defined exposed technology behavior.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Отвечает за вывод информации пользователю и интерпретирование его команд. Внешним действующим субъектом
+может быть не человек, а другая компьютерная система
+
+
+ Application Services Represent Use Cases, not CRUD
+
+Определяет задачи, которые должна решить задача, и распредеяет их межу объектами, выражающими суть предметной
+области. Задания, выполняемые этим уровнем, имеют смысл
+для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем.
+Этот уровень не нужно "раздувать" в размерах. В нем не содержатся ни знания, ни деловые регламенты (buness rles),
+а только выполняется координирование задач и распределение работы между совокупностями объектов предметной области на следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но зато он может
+содержать состояние, информирующее пользователя о степени выполнения задачи для информирования пользователя
+
+
+ Отвечает за представление понятий прикладной предметной
+области, рабочие состояния, деловые регламенты. Именно
+здесь контролируется и используется текущее состояние
+прикладной модели, пусть даже технические подробности
+манипуляций данными делеГИРУIОТСЯ инфраструктуре.
+Этот уровень является главной, алгоритмической частью
+nрограммы
+
+
+ Обеспечивает непосредственную техническую поддержку
+для верхних уровней: передачу сооБIl�ений на операционном
+уровне, непрерывность существования объектов на уровне
+модели, вывод элементов управления на уровне пользовательского интерфейса и т.д. Инфраструктурный уровень
+может также брать на себя поддержку схемы взаимосвязей
+между четырьмя уровнями через архитектурную среду приложения
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ their responsibility is to orchestrate (but don’t actually implement it) BUSINESS logic using entities and value objects
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Example of communicating services with aggregates via direct service call
+
+
+
+
+
+
+ application service layer
+
+
+
+ infrastructure layer
+
+
+
+ domain layer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Services support each other
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Example of communicating services with aggregates through events
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ my=repository.getMyById(id)
+
+my.do(amount)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MyService-MyServiceImpl and MyRepository-MyRepositoryImpl is a Bridge-pattern
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ my=repository.getMyById(id)
+
+my.do(amount)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/domain driven design patterns/F additional/CQRS Command Query Responsibility Segregation Principle/8 CQRS An Architecture of a Bounded Context.archimate b/domain driven design patterns/F additional/CQRS Command Query Responsibility Segregation Principle/8 CQRS An Architecture of a Bounded Context.archimate
index 066ce3a..2bf3293 100644
--- a/domain driven design patterns/F additional/CQRS Command Query Responsibility Segregation Principle/8 CQRS An Architecture of a Bounded Context.archimate
+++ b/domain driven design patterns/F additional/CQRS Command Query Responsibility Segregation Principle/8 CQRS An Architecture of a Bounded Context.archimate
@@ -1,20 +1,99 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Command Query Responsibility
-Segregation (CQRS)
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Command Query Responsibility
+Segregation (CQRS)
+Different layers for Commands and Queries
+
+
+
+ Assymetric layers: 3 in the case of cpmmand and 2 in case of query
+
+
+
+
+
+ CQS Command/Query Separation
+
+
+
+
+
+
+ - only input args
+- empty return result
+- side effects/change state
+
+
+
+
+
+
+ - return results
+- not side effects / no chanfge state
+
+
+
+
+
diff --git a/domain driven design patterns/F additional/CQRS Command Query Responsibility Segregation Principle/8 CQRS An Architecture of a Bounded Context.archimate.bak b/domain driven design patterns/F additional/CQRS Command Query Responsibility Segregation Principle/8 CQRS An Architecture of a Bounded Context.archimate.bak
new file mode 100644
index 0000000..de05bd1
--- /dev/null
+++ b/domain driven design patterns/F additional/CQRS Command Query Responsibility Segregation Principle/8 CQRS An Architecture of a Bounded Context.archimate.bak
@@ -0,0 +1,95 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Command Query Responsibility
+Segregation (CQRS)
+Different layers for Commands and Queries
+
+
+
+
+
+ CQS Command/Query Separation
+
+
+
+
+
+
+ - only input args
+- empty return result
+- side effects/change state
+
+
+
+
+
+
+ - return results
+- not side effects / no chanfge state
+
+
+
+
+
diff --git a/domain driven design patterns/F additional/Inversion of Control principle/Service Locator.archimate b/domain driven design patterns/F additional/Inversion of Control principle/Service Locator.archimate
index 00df277..778c768 100644
--- a/domain driven design patterns/F additional/Inversion of Control principle/Service Locator.archimate
+++ b/domain driven design patterns/F additional/Inversion of Control principle/Service Locator.archimate
@@ -1,5 +1,5 @@
-
+
@@ -198,6 +198,11 @@ interface1 = interface 1 implementation 1
interface2 = interface 2 implementation 1
+
+
+ There is a point of view that this is an antipattern,
+since when using a locator in classes, the object is often obtained from a static locator class instead of getting it from the outside in constructor with dependency injection
+
diff --git a/domain driven design patterns/F additional/Inversion of Control principle/Service Locator.archimate.bak b/domain driven design patterns/F additional/Inversion of Control principle/Service Locator.archimate.bak
new file mode 100644
index 0000000..00df277
--- /dev/null
+++ b/domain driven design patterns/F additional/Inversion of Control principle/Service Locator.archimate.bak
@@ -0,0 +1,203 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ principle of separating configuration from use
+Fawler's pattern: plugin
+Fawler's pattern: Segregated Interface
+Fawler's pattern: registry
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ To find the current implementation, we use Service Locator, in the place where we need to get the instance
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ for example,
+
+//set current implementations
+interface1 = interface 1 implementation 1
+interface2 = interface 2 implementation 1
+
+
+
+
+
diff --git a/domain driven design patterns/F additional/Inversion of Control principle/dependency injection.archimate b/domain driven design patterns/F additional/Inversion of Control principle/dependency injection.archimate
index 038e104..eaca83d 100644
--- a/domain driven design patterns/F additional/Inversion of Control principle/dependency injection.archimate
+++ b/domain driven design patterns/F additional/Inversion of Control principle/dependency injection.archimate
@@ -1,199 +1,293 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- principle of separating configuration from use
-Fawler's pattern: plugin
-Fawler's pattern: Segregated Interface
-
-- inject the implementation into the application class
-- removing the dependency from the application class to the plugin implementation
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- for example,
-
-//set current implementations
-interface1 = interface 1 implementation 1
-interface2 = interface 2 implementation 1
-
-//set init params and INJECT DEPENDENCIES
-interface1.params = instance of interface 2 implementation 1
-interface2.params = params
-
-
-
-
-
-
-
-
- The injector will automatically create the current instance of interface 2 and automatically assign it to the instance of interface 1.
-Dependencies are provided externally by a special injector and a configuration file.
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ principle of separating configuration from use
+Fawler's pattern: plugin
+Fawler's pattern: Segregated Interface
+
+- inject the implementation into the application class
+- removing the dependency from the application class to the plugin implementation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ for example,
+
+//set current implementations
+interface1 = interface 1 implementation 1
+interface2 = interface 2 implementation 1
+
+//set init params and INJECT DEPENDENCIES
+interface1.params = instance of interface 2 implementation 1
+interface2.params = params
+
+
+
+
+
+
+
+
+ The injector will automatically create the current instance of interface 2 and automatically assign it to the instance of interface 1.
+Dependencies are provided externally by a special injector and a configuration file.
+
+
+
+
+
+ the diagram demonstrates the basic concepts of DI:
+- the main component
+- root of composition
+- recognition root - first recognized and injected class (the root of the object graph to be recognized)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Composition root
+
+
+
+
+
+
+
+
+ the main component
+- it provides only the workability of the system .
+- his task is to create all Factories, Strategies and other global tools and then transfer control to high-level abstractions in the system .
+- it is in the main component that all dependencies should be implemented using the dependency injection infrastructure
+- the lowest level dirty module located in the outer circle of pure architecture . It loads whatever the higher-level system needs and then transfers control to it .
+- think of the main component as a plug-in,
+
+
+
+
+
+
+ find all the appropriate controller classes, select the most appropriate one, create a controller instance, and implement the dependency on that instance
+
+
+
+
+
+
+
+
+
+
+
+
+ Recognition root
+
+
+
+
+
+
+
+
+
+
+ DI container also Inject Dependency to the service instance (find appropriate class and create instance before it)
+
+
+
+
diff --git a/domain driven design patterns/F additional/Inversion of Control principle/dependency injection.archimate.bak b/domain driven design patterns/F additional/Inversion of Control principle/dependency injection.archimate.bak
new file mode 100644
index 0000000..3df09c4
--- /dev/null
+++ b/domain driven design patterns/F additional/Inversion of Control principle/dependency injection.archimate.bak
@@ -0,0 +1,292 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ principle of separating configuration from use
+Fawler's pattern: plugin
+Fawler's pattern: Segregated Interface
+
+- inject the implementation into the application class
+- removing the dependency from the application class to the plugin implementation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ for example,
+
+//set current implementations
+interface1 = interface 1 implementation 1
+interface2 = interface 2 implementation 1
+
+//set init params and INJECT DEPENDENCIES
+interface1.params = instance of interface 2 implementation 1
+interface2.params = params
+
+
+
+
+
+
+
+
+ The injector will automatically create the current instance of interface 2 and automatically assign it to the instance of interface 1.
+Dependencies are provided externally by a special injector and a configuration file.
+
+
+
+
+
+ the diagram demonstrates the basic concepts of DI:
+- root of composition
+- recognition root - first recognized and injected class (the root of the object graph to be recognized)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Composition root
+
+
+
+
+
+
+
+
+ the main component
+- it provides only the workability of the system .
+- his task is to create all Factories, Strategies and other global tools and then transfer control to high-level abstractions in the system .
+- it is in the main component that all dependencies should be implemented using the dependency injection infrastructure
+- the lowest level dirty module located in the outer circle of pure architecture . It loads whatever the higher-level system needs and then transfers control to it .
+- think of the main component as a plug-in,
+
+
+
+
+
+
+ find all the appropriate controller classes, select the most appropriate one, create a controller instance, and implement the dependency on that instance
+
+
+
+
+
+
+
+
+
+
+
+
+ Recognition root
+
+
+
+
+
+
+
+
+
+
+ DI container also Inject Dependency to the service instance (find appropriate class and create instance before it)
+
+
+
+
diff --git a/domain driven design patterns/F additional/clean architecture/Untitled1 bad.archimate b/domain driven design patterns/F additional/clean architecture/Untitled1 bad.archimate
new file mode 100644
index 0000000..3a33101
--- /dev/null
+++ b/domain driven design patterns/F additional/clean architecture/Untitled1 bad.archimate
@@ -0,0 +1,1582 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ all concrete classes can use factory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blue lines - calculate payroll
+gray lines - add employee
+green lines - add value objects to employee
+
+
+
+
+ date, startDate, grossPay, deductions, netPay
+
+
+
+ uses all time-cards for calculate pay
+
+
+
+ Uses all sales-receipts to calculate pay
+
+
+
+ Uses all service-charges to calculate fee
+
+
+
+ Payroll system example from Robert Martin book Agile Software Development, Principles, Patterns, and Practices.
+Please note that PaymentClassification has methods specific to its subclasses: addTimeCard and addSalesReceipt
+that violates Liskov's substitution principle
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ date, startDate, grossPay, deductions, netPay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ all concrete classes can use factory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Uses all sales-receipts to calculate pay
+
+
+
+ uses all time-cards for calculate pay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Uses all service-charges to calculate fee
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Clean architecture devided by Java packages or C# namespaces
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Bad pattern. Without factory ServiceImplementation directly depends on ModelImplementation
+
+
+
+
+
+
+
+
+
+
+
+
+
+ without factory ServiceImplementation directly depends on ModelImplementation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/domain driven design patterns/F additional/clean architecture/Untitled1 bad.archimate.bak b/domain driven design patterns/F additional/clean architecture/Untitled1 bad.archimate.bak
new file mode 100644
index 0000000..fe7b581
--- /dev/null
+++ b/domain driven design patterns/F additional/clean architecture/Untitled1 bad.archimate.bak
@@ -0,0 +1,1641 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ all concrete classes can use factory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blue lines - calculate payroll
+gray lines - add employee
+green lines - add value objects to employee
+
+
+
+
+ date, startDate, grossPay, deductions, netPay
+
+
+
+ uses all time-cards for calculate pay
+
+
+
+ Uses all sales-receipts to calculate pay
+
+
+
+ Uses all service-charges to calculate fee
+
+
+
+ Payroll system example from Robert Martin book Agile Software Development, Principles, Patterns, and Practices.
+Please note that PaymentClassification has methods specific to its subclasses: addTimeCard and addSalesReceipt
+that violates Liskov's substitution principle
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ date, startDate, grossPay, deductions, netPay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ all concrete classes can use factory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Uses all sales-receipts to calculate pay
+
+
+
+ uses all time-cards for calculate pay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Uses all service-charges to calculate fee
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Clean architecture devided by Java packages or C# namespaces
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/domain driven design patterns/F additional/clean architecture/Untitled1.archimate b/domain driven design patterns/F additional/clean architecture/Untitled1.archimate
new file mode 100644
index 0000000..8fd78a0
--- /dev/null
+++ b/domain driven design patterns/F additional/clean architecture/Untitled1.archimate
@@ -0,0 +1,1937 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ all concrete classes can use factory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blue lines - calculate payroll
+gray lines - add employee
+green lines - add value objects to employee
+
+
+
+
+ date, startDate, grossPay, deductions, netPay
+
+
+
+ uses all time-cards for calculate pay
+
+
+
+ Uses all sales-receipts to calculate pay
+
+
+
+ Uses all service-charges to calculate fee
+
+
+
+ Payroll system example from Robert Martin book Agile Software Development, Principles, Patterns, and Practices.
+Please note that PaymentClassification has methods specific to its subclasses: addTimeCard and addSalesReceipt
+that violates Liskov's substitution principle
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ date, startDate, grossPay, deductions, netPay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ all concrete classes can use factory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Uses all sales-receipts to calculate pay
+
+
+
+ uses all time-cards for calculate pay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Uses all service-charges to calculate fee
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Clean architecture devided by Java packages or C# namespaces
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Package by layer
+
+green - public packages opened to other packages
+white - private packages in module/jar
+gray - java jar or gradle project
+
+
+
+ One jar receives service implementation through java ServiceLoader, which only needs to know the interface to load a particular class
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Package by feature
+
+green - public packages in module/jar
+white - private packages in module/jar
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “ports and adapters,
+”the “hexagonal architecture,”
+“boundaries, controllers, entities,”
+
+green - public packages in module/jar
+white - private packages in module/jar
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Package by component
+MSA microservices architecture style
+
+green - public packages in module/jar
+white - private packages in module/jar
+
+
+
+
diff --git a/domain driven design patterns/F additional/clean architecture/Untitled1.archimate.bak b/domain driven design patterns/F additional/clean architecture/Untitled1.archimate.bak
new file mode 100644
index 0000000..4ef6789
--- /dev/null
+++ b/domain driven design patterns/F additional/clean architecture/Untitled1.archimate.bak
@@ -0,0 +1,1937 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ all concrete classes can use factory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blue lines - calculate payroll
+gray lines - add employee
+green lines - add value objects to employee
+
+
+
+
+ date, startDate, grossPay, deductions, netPay
+
+
+
+ uses all time-cards for calculate pay
+
+
+
+ Uses all sales-receipts to calculate pay
+
+
+
+ Uses all service-charges to calculate fee
+
+
+
+ Payroll system example from Robert Martin book Agile Software Development, Principles, Patterns, and Practices.
+Please note that PaymentClassification has methods specific to its subclasses: addTimeCard and addSalesReceipt
+that violates Liskov's substitution principle
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ date, startDate, grossPay, deductions, netPay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ all concrete classes can use factory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Uses all sales-receipts to calculate pay
+
+
+
+ uses all time-cards for calculate pay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Uses all service-charges to calculate fee
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Clean architecture devided by Java packages or C# namespaces
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Package by layer
+
+green - public packages opened to other packages
+white - private packages in module/jar
+gray - java jar or gradle project
+
+
+
+ One jar receives service implementation through java ServiceLoader, which only needs to know the interface to load a particular class
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Package by feature
+
+green - public packages in module/jar
+white - private packages in module/jar
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “ports and adapters,
+”the “hexagonal architecture,”
+“boundaries, controllers, entities,”
+
+green - public packages in module/jar
+white - private packages in module/jar
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Package by component
+MSA microservices architecture style
+
+green - public packages in module/jar
+white - private packages in module/jar
+
+
+
+
diff --git a/domain driven design patterns/F additional/clean architecture/clean1.archimate b/domain driven design patterns/F additional/clean architecture/clean1.archimate
new file mode 100644
index 0000000..85c00f3
--- /dev/null
+++ b/domain driven design patterns/F additional/clean architecture/clean1.archimate
@@ -0,0 +1,14 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/domain driven design patterns/F additional/examples/33 app example 4 (domain model).archimate b/domain driven design patterns/F additional/examples/33 app example 4 (domain model).archimate
index c101865..5d60a0d 100644
--- a/domain driven design patterns/F additional/examples/33 app example 4 (domain model).archimate
+++ b/domain driven design patterns/F additional/examples/33 app example 4 (domain model).archimate
@@ -1,181 +1,427 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Application Services Layer (operational)
-
-
-
- Domain Layer (model)
-
-
-
- Infrаstrсtиrе Layer
-
-
-
- Application Services Layer (operational)
-
-
-
- Presentation Layer (User Interface)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Clients who will use the interface are also dependent on the class2, it is mentioned in the interface
+
+
+
+ AS IS
+
+
+
+ TO BE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Now the external dependency is declared as a constructor parameter and not a method parameter and does not clog the interface
+
+
+
+
+
+ Application Services Layer (operational)
+
+
+
+ Domain Layer (model)
+
+
+
+ Infrаstrсtиrе Layer
+
+
+
+ Application Services Layer (operational)
+
+
+
+ Presentation Layer (User Interface)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ each class has its own responsibility
+
+
+
+ the facade for convenience combines / exposes the diverse functionality that other classes provide
+
+
+
+
diff --git a/domain driven design patterns/F additional/examples/33 app example 4 (domain model).archimate.bak b/domain driven design patterns/F additional/examples/33 app example 4 (domain model).archimate.bak
new file mode 100644
index 0000000..8d759ed
--- /dev/null
+++ b/domain driven design patterns/F additional/examples/33 app example 4 (domain model).archimate.bak
@@ -0,0 +1,416 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Clients who will use the interface are also dependent on the class2, it is mentioned in the interface
+
+
+
+ AS IS
+
+
+
+ TO BE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Now the external dependency is declared as a constructor parameter and not a method parameter and does not clog the interface
+
+
+
+
+
+ Application Services Layer (operational)
+
+
+
+ Domain Layer (model)
+
+
+
+ Infrаstrсtиrе Layer
+
+
+
+ Application Services Layer (operational)
+
+
+
+ Presentation Layer (User Interface)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Application Services Layer (operational)
+
+
+
+ Domain Layer (model)
+
+
+
+ Infrаstrсtиrе Layer
+
+
+
+ Application Services Layer (operational)
+
+
+
+ Presentation Layer (User Interface)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/patterns.pdf b/patterns.pdf
new file mode 100644
index 0000000..a66fee2
Binary files /dev/null and b/patterns.pdf differ
diff --git a/patternsbookcover.png b/patternsbookcover.png
new file mode 100644
index 0000000..05e4f15
Binary files /dev/null and b/patternsbookcover.png differ