SlideShare ist ein Scribd-Unternehmen logo
1 von 40
Downloaden Sie, um offline zu lesen
Crafted Design
Sandro Mancuso
@sandromancuso
http://leanpub.com/socra
Crafted Design - ITAKE 2014
 What is this application about?
 What are the main concepts?
 What does this application do?
 What are the main features?
 Where do I need to change?
 Where do I put a new feature?
 Looking from above, I can’t see what the application
does or is about
 Architectural and design concepts mixed with domain
 Badly structured packages/namespaces
 I don’t know where to start
 Classes and methods are too low level
Example: Layered structure
Example: Layered-domain structure
Example: MVC structure
Crafted Design - ITAKE 2014
MVC & MVC Variations
• MVC (Smalltalk 76/80)
• MVC (general concept – 1988)
• Three-Tier Architecture (Presentation, Logic,
Data)
• MVC (Model 1/Model 2)
• Model View Adapter (MVA)
• Model View Presenter (MVP)
• Model View ViewModel (MVVM)
• Presentation-Abstraction-Control (PAC)
• ….
MVC
used
badly
Anaemic
Domain
Fat
Controllers
Coupling
with MVC
framework
MVC & MVC Variations
They are all right. And they are wrong. It all depends on the ‘V’iew.
Views impact MVC structure
Depending on the view technology, Views and Controllers
responsibility becomes more/less coupled or blurred.
 Web applications
 Single-page AJAX applications with stateless backend
 Console-based applications
 Desktop applications
 Games
 Mobile / tablets
 External systems (talking via Queues / Webservices)
However, the model should remain unchanged.
MVC – A Macro Organisational Pattern
Model
V C M
Delivery
Mechanism
“Model” is overloaded and
confusing
 Model (M in MVC)
 Domain Model (DDD)
 View Model
 Data Model
 Entities & Active Record
 and other artificial definitions from MVC frameworks
 Associated with the persistence mechanism?
M => Domain Model (DDD)
Domain Model combines state and behaviour,
with more focus on the latter.
DDD define a few building blocks to your domain:
 Entities
 Value Objects
 Factories
 Repositories
 Services
 Application
 Domain
 Infrastructure
 Aggregates
<< Web app >>
Embedded Domain Model
Model
V C DM
Delivery
Mechanism
Infrastructure Infrastructure
DB
Queue
Deployable Domain Model
Delivery
Mechanisms
<< external system >>
<< mobile app >>
DB
<< deployable app >>
Model
Infrastructure
DM<<W/S>>
<<W/S>>
Event-Driven Domain Model
Delivery
Mechanisms DB
Queue
<< external app 2 >>
<< external app 1 >> << deployable app >>
Model
Infrastructure
DMQueue
<<event 1>>
<<event 2>>
Domain Model
building blocks & responsibilities
A = Action, DS = Domain Service, S = Infra. Service, R = Repository
Model
A 1
R 3
DS 1
DS 3
R 1
S
Infrastructure Impl
DM
DS 2
Impl
A 2
<< web app >>
Behaviour: Action, Domain Service or Entity?
Domain
Service
Entity
Action Defines the action our domain model will be asked
to perform.
Behaviour related to multiple instances of the same entity
or different entities.
Behaviour that doesn’t fit any specific entity.
Behaviour related to the data of a single instance of
an entity
Repositories (not DAOs)
Model
<<repository>>
Library
<<repository>>
Users
Infrastructure
<<Mongo>>
Books
Domain Model
<<Oracle>>
Users
“A Repository represents all objects of a certain type as a conceptual set. It acts
like a collection, except with more elaborate querying capability.”
~ Eric Evans
An example would be good…
Order
Service Orders
<<interface>>
Card Processor
Payment
ValidatorMake
Payment
User Account
Service
Usersvalid account?
Payment
Gatewaypay
has prime account?
process card
validate
store order
Action Domain Service Infra. Service Repository Class
<<interface>>
Email Sender
email confirmation
Class responsibility
C A DS R
cl
Input Output
End of code branch
Produces the output
End of flow
First to handle input
Start of the flow
Execution Flow
 Closer to the input: Control flow, higher level abstraction, detailed work is delegated
(e.g. ProcessTrade (A), MakePayment (A)) — More suitable for Outside-In TDD
(mockist).
 Closer to the output / end of branch: Specific and detailed behaviour, no delegation,
lower level abstraction (e.g. Parse XML (Parser), Create User (Repository))
Domain Model entry
point Domain Concept
entry point
Domain Model collaborations guideline
C1
A 1
A 2
DS 1
DS 4
DS 3
R 4
R 1
cl
cl
cl
cl
C = Controller, A = Action, DS = Domain Service, R = Repository, cl = class
DS 2
X
A 3 R 5XC2 Except for read model
X
Command & Query Actions
<< web app >>
Model
R
DS
<<Write Model>>
A
Model
<<Read Model>>
A R
DB
DB
Queue <<domain events>>
So, how does the app structure look like?
Web project responsibility
Control flow (invoke actions)
JSON / XML parsers or converters
View Models, validators, etc
Static files
Delivery Mechanism: Defines the user journey
Core responsibility (simple project)
Tells what the system is about
Tells what the system does
Core responsibility (bigger project)
Epic / Theme
Epic / Theme
Epic / Theme
Related domain concepts
What is inside model packages?
Aggregate root (entity)
Repository
Entity (part of Book aggregate)
Domain Service
Value Object (part of Book aggregate)
Part of aggregate behaviour
Repository
Value Object (part of User aggregate)
Aggregate root (entity)
Domain Service
What is inside infrastructure?
Interfaces defined by the domain.
Dependency Inversion Principle (DIP)
CreditCardProcessor implementations
Repository implementations
Defining testing strategies and boundaries
• Unit
• Integration
• Acceptance
• Journey
• Black box
• Component
• System
• Functional
• Alpha
• Beta
• Conformance
• …
Types of tests
Testing strategies: User Journey
Model
A 1
DM
A 2
<< web app >>
A 1
A 2
Tests the journey a user will have to do something
useful in the system
Application is tested as a black box normally using
a BDD framework
Actions are faked. We just want to know if the
application presents the user with the correct
journey
Designed according to User Stories
and Features
<<fake>>
<<fake>>
Infrastructure Impl
Testing strategies: Acceptance (Action / Behavioural)
A DS 1
<<mock>>
RDS 2 R
Tests a behaviour (action) provided by the system
Action is the entry point and
all external dependencies are
stubbed
Domain Model
Normally tested using a BDD
framework
Testing strategies: Integration
Tests the classes at the system boundaries
Infrastructure Impl
A DS 1
<<mock>>
RDS 2 R
Domain Model
Normally done using an in-
memory Database using a unit
testing framework
Testing strategies: Unit (Class level)
Unit test at class/method level
Infrastructure
Impl
A DS 1
RRDS 2
Domain Model
DS 1
DS 2
All collaborators are
mocked / stubbed
(spies)
Testing strategies: End-to-End
Model
A 1
R 3
DS 1
DS 3
R 1
S
Infrastructure Impl
DM
DS 2
Impl
A 2
<< web app >>
Full application deployed
Uses BDD framework, accessing a testing database and
fake external dependencies
Very few tests at this level, just to make sure
application is wired properly
Interaction-Driven Design – IDD
(Outside-In design)
C A DS R
cl
Input Output
Execution Flow
 Starting from the action, model the expected behaviour (outside-in)
 Entities (data structures) will emerge in order to satisfy the behaviour
 Focus is on the behaviour of the system and not on how data is stored/related
Design Flow
Answering the two original questions
 What is the application about? (main concepts)
 What does the application do? (main features)
Expressed by nouns
Expressed by verbs
(Actions)
Thank You
http://leanpub.com/socra
@sandromancuso

Más contenido relacionado

Was ist angesagt?

Activities, Fragments, and Events
Activities, Fragments, and EventsActivities, Fragments, and Events
Activities, Fragments, and EventsHenry Osborne
 
Clean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a MonolithClean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
 
Functional Patterns with Java8 @Bucharest Java User Group
Functional Patterns with Java8 @Bucharest Java User GroupFunctional Patterns with Java8 @Bucharest Java User Group
Functional Patterns with Java8 @Bucharest Java User GroupVictor Rentea
 
Clean pragmatic architecture @ devflix
Clean pragmatic architecture @ devflixClean pragmatic architecture @ devflix
Clean pragmatic architecture @ devflixVictor Rentea
 
Domain Driven Design with the F# type System -- NDC London 2013
Domain Driven Design with the F# type System -- NDC London 2013Domain Driven Design with the F# type System -- NDC London 2013
Domain Driven Design with the F# type System -- NDC London 2013Scott Wlaschin
 
Domain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesDomain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesiMasters
 
Event sourcing in the functional world (22 07-2021)
Event sourcing in the functional world (22 07-2021)Event sourcing in the functional world (22 07-2021)
Event sourcing in the functional world (22 07-2021)Vitaly Brusentsev
 
Don't Be Mocked by your Mocks - Best Practices using Mocks
Don't Be Mocked by your Mocks - Best Practices using MocksDon't Be Mocked by your Mocks - Best Practices using Mocks
Don't Be Mocked by your Mocks - Best Practices using MocksVictor Rentea
 
Class and Objects in PHP
Class and Objects in PHPClass and Objects in PHP
Class and Objects in PHPRamasubbu .P
 
Lambda and Stream Master class - part 1
Lambda and Stream Master class - part 1Lambda and Stream Master class - part 1
Lambda and Stream Master class - part 1José Paumard
 
Practical Occlusion Culling in Killzone 3
Practical Occlusion Culling in Killzone 3Practical Occlusion Culling in Killzone 3
Practical Occlusion Culling in Killzone 3Guerrilla
 
L'API Collector dans tous ses états
L'API Collector dans tous ses étatsL'API Collector dans tous ses états
L'API Collector dans tous ses étatsJosé Paumard
 
predefined and user defined functions
predefined and user defined functionspredefined and user defined functions
predefined and user defined functionsSwapnil Yadav
 
Applying Domain-Driven Design to craft Rich Domain Models
Applying Domain-Driven Design to craft Rich Domain ModelsApplying Domain-Driven Design to craft Rich Domain Models
Applying Domain-Driven Design to craft Rich Domain ModelsAlexander van Trijffel
 
Refactoring for Domain Driven Design
Refactoring for Domain Driven DesignRefactoring for Domain Driven Design
Refactoring for Domain Driven DesignDavid Berliner
 
Laravel Design Patterns
Laravel Design PatternsLaravel Design Patterns
Laravel Design PatternsBobby Bouwmann
 
Enterprise Software Architecture styles
Enterprise Software Architecture stylesEnterprise Software Architecture styles
Enterprise Software Architecture stylesAraf Karsh Hamid
 
A Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation SlidesA Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation Slidesthinkddd
 

Was ist angesagt? (20)

Activities, Fragments, and Events
Activities, Fragments, and EventsActivities, Fragments, and Events
Activities, Fragments, and Events
 
Clean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a MonolithClean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a Monolith
 
Functional Patterns with Java8 @Bucharest Java User Group
Functional Patterns with Java8 @Bucharest Java User GroupFunctional Patterns with Java8 @Bucharest Java User Group
Functional Patterns with Java8 @Bucharest Java User Group
 
jQuery for beginners
jQuery for beginnersjQuery for beginners
jQuery for beginners
 
Clean pragmatic architecture @ devflix
Clean pragmatic architecture @ devflixClean pragmatic architecture @ devflix
Clean pragmatic architecture @ devflix
 
Domain Driven Design with the F# type System -- NDC London 2013
Domain Driven Design with the F# type System -- NDC London 2013Domain Driven Design with the F# type System -- NDC London 2013
Domain Driven Design with the F# type System -- NDC London 2013
 
Domain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesDomain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
 
Event sourcing in the functional world (22 07-2021)
Event sourcing in the functional world (22 07-2021)Event sourcing in the functional world (22 07-2021)
Event sourcing in the functional world (22 07-2021)
 
Don't Be Mocked by your Mocks - Best Practices using Mocks
Don't Be Mocked by your Mocks - Best Practices using MocksDon't Be Mocked by your Mocks - Best Practices using Mocks
Don't Be Mocked by your Mocks - Best Practices using Mocks
 
Class and Objects in PHP
Class and Objects in PHPClass and Objects in PHP
Class and Objects in PHP
 
Lambda and Stream Master class - part 1
Lambda and Stream Master class - part 1Lambda and Stream Master class - part 1
Lambda and Stream Master class - part 1
 
Practical Occlusion Culling in Killzone 3
Practical Occlusion Culling in Killzone 3Practical Occlusion Culling in Killzone 3
Practical Occlusion Culling in Killzone 3
 
L'API Collector dans tous ses états
L'API Collector dans tous ses étatsL'API Collector dans tous ses états
L'API Collector dans tous ses états
 
predefined and user defined functions
predefined and user defined functionspredefined and user defined functions
predefined and user defined functions
 
Applying Domain-Driven Design to craft Rich Domain Models
Applying Domain-Driven Design to craft Rich Domain ModelsApplying Domain-Driven Design to craft Rich Domain Models
Applying Domain-Driven Design to craft Rich Domain Models
 
Refactoring for Domain Driven Design
Refactoring for Domain Driven DesignRefactoring for Domain Driven Design
Refactoring for Domain Driven Design
 
Laravel Design Patterns
Laravel Design PatternsLaravel Design Patterns
Laravel Design Patterns
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Enterprise Software Architecture styles
Enterprise Software Architecture stylesEnterprise Software Architecture styles
Enterprise Software Architecture styles
 
A Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation SlidesA Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation Slides
 

Andere mochten auch

BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014
BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014
BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014TSundberg
 
Tom Gilb - Power to the Programmers @ I T.A.K.E. Unconference 2014, Bucharest
Tom Gilb - Power to the Programmers @ I T.A.K.E. Unconference 2014, BucharestTom Gilb - Power to the Programmers @ I T.A.K.E. Unconference 2014, Bucharest
Tom Gilb - Power to the Programmers @ I T.A.K.E. Unconference 2014, BucharestMozaic Works
 
Hands on continouous delivery, I TAKE 2014
Hands on continouous delivery, I TAKE 2014Hands on continouous delivery, I TAKE 2014
Hands on continouous delivery, I TAKE 2014Ioan Eugen Stan
 
Leading Tech Teams
Leading Tech TeamsLeading Tech Teams
Leading Tech TeamsFlavius Stef
 
Refactoring Legacy Code - true story
Refactoring Legacy Code - true storyRefactoring Legacy Code - true story
Refactoring Legacy Code - true storyAki Salmi
 
Putting the science in computer science
Putting the science in computer sciencePutting the science in computer science
Putting the science in computer scienceFelienne Hermans
 
Crafted Design - GeeCON 2014
Crafted Design - GeeCON 2014Crafted Design - GeeCON 2014
Crafted Design - GeeCON 2014Sandro Mancuso
 
Software Craftsmanship
Software CraftsmanshipSoftware Craftsmanship
Software CraftsmanshipSandro Mancuso
 
Legacy Code Hands-on Session
Legacy Code Hands-on Session Legacy Code Hands-on Session
Legacy Code Hands-on Session Sandro Mancuso
 
Software Craftsmanship - JAX London 2011
Software Craftsmanship - JAX London 2011Software Craftsmanship - JAX London 2011
Software Craftsmanship - JAX London 2011Sandro Mancuso
 
Crafted Design - Sandro Mancuso
Crafted Design - Sandro MancusoCrafted Design - Sandro Mancuso
Crafted Design - Sandro MancusoJAXLondon2014
 
Sandro Mancuso - Software Craftmanship @ I T.A.K.E. Unconference 2013, Bucharest
Sandro Mancuso - Software Craftmanship @ I T.A.K.E. Unconference 2013, BucharestSandro Mancuso - Software Craftmanship @ I T.A.K.E. Unconference 2013, Bucharest
Sandro Mancuso - Software Craftmanship @ I T.A.K.E. Unconference 2013, BucharestMozaic Works
 
Erik talboom - TDD as if The Baby Meant it @I T.A.K.E. Unconference 2013, Buc...
Erik talboom - TDD as if The Baby Meant it @I T.A.K.E. Unconference 2013, Buc...Erik talboom - TDD as if The Baby Meant it @I T.A.K.E. Unconference 2013, Buc...
Erik talboom - TDD as if The Baby Meant it @I T.A.K.E. Unconference 2013, Buc...Mozaic Works
 
Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...
Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...
Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...Mozaic Works
 
Functional Principles for OO Developers
Functional Principles for OO DevelopersFunctional Principles for OO Developers
Functional Principles for OO Developersjessitron
 
Simplifying your design with higher-order functions
Simplifying your design with higher-order functionsSimplifying your design with higher-order functions
Simplifying your design with higher-order functionsSamir Talwar
 
I T.A.K.E. talk: "When DDD meets FP, good things happen"
I T.A.K.E. talk: "When DDD meets FP, good things happen"I T.A.K.E. talk: "When DDD meets FP, good things happen"
I T.A.K.E. talk: "When DDD meets FP, good things happen"Cyrille Martraire
 
The Good the Bad and the Ugly of Dealing with Smelly Code (ITAKE Unconference)
The Good the Bad and the Ugly of Dealing with Smelly Code (ITAKE Unconference)The Good the Bad and the Ugly of Dealing with Smelly Code (ITAKE Unconference)
The Good the Bad and the Ugly of Dealing with Smelly Code (ITAKE Unconference)Radu Marinescu
 

Andere mochten auch (20)

BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014
BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014
BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014
 
Tom Gilb - Power to the Programmers @ I T.A.K.E. Unconference 2014, Bucharest
Tom Gilb - Power to the Programmers @ I T.A.K.E. Unconference 2014, BucharestTom Gilb - Power to the Programmers @ I T.A.K.E. Unconference 2014, Bucharest
Tom Gilb - Power to the Programmers @ I T.A.K.E. Unconference 2014, Bucharest
 
Hands on continouous delivery, I TAKE 2014
Hands on continouous delivery, I TAKE 2014Hands on continouous delivery, I TAKE 2014
Hands on continouous delivery, I TAKE 2014
 
Leading Tech Teams
Leading Tech TeamsLeading Tech Teams
Leading Tech Teams
 
Cqrs in babysteps
Cqrs in babystepsCqrs in babysteps
Cqrs in babysteps
 
Refactoring Legacy Code - true story
Refactoring Legacy Code - true storyRefactoring Legacy Code - true story
Refactoring Legacy Code - true story
 
Putting the science in computer science
Putting the science in computer sciencePutting the science in computer science
Putting the science in computer science
 
Crafted Design - GeeCON 2014
Crafted Design - GeeCON 2014Crafted Design - GeeCON 2014
Crafted Design - GeeCON 2014
 
Software Craftsmanship
Software CraftsmanshipSoftware Craftsmanship
Software Craftsmanship
 
Legacy Code Hands-on Session
Legacy Code Hands-on Session Legacy Code Hands-on Session
Legacy Code Hands-on Session
 
Software Craftsmanship - JAX London 2011
Software Craftsmanship - JAX London 2011Software Craftsmanship - JAX London 2011
Software Craftsmanship - JAX London 2011
 
Crafted design
Crafted designCrafted design
Crafted design
 
Crafted Design - Sandro Mancuso
Crafted Design - Sandro MancusoCrafted Design - Sandro Mancuso
Crafted Design - Sandro Mancuso
 
Sandro Mancuso - Software Craftmanship @ I T.A.K.E. Unconference 2013, Bucharest
Sandro Mancuso - Software Craftmanship @ I T.A.K.E. Unconference 2013, BucharestSandro Mancuso - Software Craftmanship @ I T.A.K.E. Unconference 2013, Bucharest
Sandro Mancuso - Software Craftmanship @ I T.A.K.E. Unconference 2013, Bucharest
 
Erik talboom - TDD as if The Baby Meant it @I T.A.K.E. Unconference 2013, Buc...
Erik talboom - TDD as if The Baby Meant it @I T.A.K.E. Unconference 2013, Buc...Erik talboom - TDD as if The Baby Meant it @I T.A.K.E. Unconference 2013, Buc...
Erik talboom - TDD as if The Baby Meant it @I T.A.K.E. Unconference 2013, Buc...
 
Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...
Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...
Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...
 
Functional Principles for OO Developers
Functional Principles for OO DevelopersFunctional Principles for OO Developers
Functional Principles for OO Developers
 
Simplifying your design with higher-order functions
Simplifying your design with higher-order functionsSimplifying your design with higher-order functions
Simplifying your design with higher-order functions
 
I T.A.K.E. talk: "When DDD meets FP, good things happen"
I T.A.K.E. talk: "When DDD meets FP, good things happen"I T.A.K.E. talk: "When DDD meets FP, good things happen"
I T.A.K.E. talk: "When DDD meets FP, good things happen"
 
The Good the Bad and the Ugly of Dealing with Smelly Code (ITAKE Unconference)
The Good the Bad and the Ugly of Dealing with Smelly Code (ITAKE Unconference)The Good the Bad and the Ugly of Dealing with Smelly Code (ITAKE Unconference)
The Good the Bad and the Ugly of Dealing with Smelly Code (ITAKE Unconference)
 

Ähnlich wie Crafted Design - ITAKE 2014

Onion Architecture with S#arp
Onion Architecture with S#arpOnion Architecture with S#arp
Onion Architecture with S#arpGary Pedretti
 
Introduction to SOFTWARE ARCHITECTURE
Introduction to SOFTWARE ARCHITECTUREIntroduction to SOFTWARE ARCHITECTURE
Introduction to SOFTWARE ARCHITECTUREIvano Malavolta
 
MVC Pattern. Flex implementation of MVC
MVC Pattern. Flex implementation of MVCMVC Pattern. Flex implementation of MVC
MVC Pattern. Flex implementation of MVCAnton Krasnoshchok
 
The Magic Of Application Lifecycle Management In Vs Public
The Magic Of Application Lifecycle Management In Vs PublicThe Magic Of Application Lifecycle Management In Vs Public
The Magic Of Application Lifecycle Management In Vs PublicDavid Solivan
 
DQ Product Usage Methodology Highlights_v6_ltd
DQ Product Usage Methodology Highlights_v6_ltdDQ Product Usage Methodology Highlights_v6_ltd
DQ Product Usage Methodology Highlights_v6_ltdDigendra Vir Singh (DV)
 
Overview of atg framework
Overview of atg frameworkOverview of atg framework
Overview of atg frameworkYousuf Roushan
 
Architectural Patterns and Software Architectures: Client-Server, Multi-Tier,...
Architectural Patterns and Software Architectures: Client-Server, Multi-Tier,...Architectural Patterns and Software Architectures: Client-Server, Multi-Tier,...
Architectural Patterns and Software Architectures: Client-Server, Multi-Tier,...Svetlin Nakov
 
Action-Domain-Responder: A Web-Specific Refinement of Model-View-Controller
Action-Domain-Responder: A Web-Specific Refinement of Model-View-ControllerAction-Domain-Responder: A Web-Specific Refinement of Model-View-Controller
Action-Domain-Responder: A Web-Specific Refinement of Model-View-ControllerPaul Jones
 
"Up-Down Development & DSL-first approach", Владимир Мельник, DataArt
 "Up-Down Development & DSL-first approach", Владимир Мельник, DataArt "Up-Down Development & DSL-first approach", Владимир Мельник, DataArt
"Up-Down Development & DSL-first approach", Владимир Мельник, DataArtDataArt
 
Clean architecture with asp.net core
Clean architecture with asp.net coreClean architecture with asp.net core
Clean architecture with asp.net coreSam Nasr, MCSA, MVP
 
[2017/2018] Introduction to Software Architecture
[2017/2018] Introduction to Software Architecture[2017/2018] Introduction to Software Architecture
[2017/2018] Introduction to Software ArchitectureIvano Malavolta
 
Multi-tenancy with Rails
Multi-tenancy with RailsMulti-tenancy with Rails
Multi-tenancy with RailsPaul Gallagher
 
Modern Database Development Oow2008 Lucas Jellema
Modern Database Development Oow2008 Lucas JellemaModern Database Development Oow2008 Lucas Jellema
Modern Database Development Oow2008 Lucas JellemaLucas Jellema
 
Understanding angular js
Understanding angular jsUnderstanding angular js
Understanding angular jsAayush Shrestha
 
OORPT Dynamic Analysis
OORPT Dynamic AnalysisOORPT Dynamic Analysis
OORPT Dynamic Analysislienhard
 
[2016/2017] Introduction to Software Architecture
[2016/2017] Introduction to Software Architecture[2016/2017] Introduction to Software Architecture
[2016/2017] Introduction to Software ArchitectureIvano Malavolta
 

Ähnlich wie Crafted Design - ITAKE 2014 (20)

Onion Architecture with S#arp
Onion Architecture with S#arpOnion Architecture with S#arp
Onion Architecture with S#arp
 
Introduction to SOFTWARE ARCHITECTURE
Introduction to SOFTWARE ARCHITECTUREIntroduction to SOFTWARE ARCHITECTURE
Introduction to SOFTWARE ARCHITECTURE
 
MVC Pattern. Flex implementation of MVC
MVC Pattern. Flex implementation of MVCMVC Pattern. Flex implementation of MVC
MVC Pattern. Flex implementation of MVC
 
The Magic Of Application Lifecycle Management In Vs Public
The Magic Of Application Lifecycle Management In Vs PublicThe Magic Of Application Lifecycle Management In Vs Public
The Magic Of Application Lifecycle Management In Vs Public
 
DQ Product Usage Methodology Highlights_v6_ltd
DQ Product Usage Methodology Highlights_v6_ltdDQ Product Usage Methodology Highlights_v6_ltd
DQ Product Usage Methodology Highlights_v6_ltd
 
Overview of atg framework
Overview of atg frameworkOverview of atg framework
Overview of atg framework
 
Architectural Patterns and Software Architectures: Client-Server, Multi-Tier,...
Architectural Patterns and Software Architectures: Client-Server, Multi-Tier,...Architectural Patterns and Software Architectures: Client-Server, Multi-Tier,...
Architectural Patterns and Software Architectures: Client-Server, Multi-Tier,...
 
Action-Domain-Responder: A Web-Specific Refinement of Model-View-Controller
Action-Domain-Responder: A Web-Specific Refinement of Model-View-ControllerAction-Domain-Responder: A Web-Specific Refinement of Model-View-Controller
Action-Domain-Responder: A Web-Specific Refinement of Model-View-Controller
 
J2EE pattern 5
J2EE pattern 5J2EE pattern 5
J2EE pattern 5
 
"Up-Down Development & DSL-first approach", Владимир Мельник, DataArt
 "Up-Down Development & DSL-first approach", Владимир Мельник, DataArt "Up-Down Development & DSL-first approach", Владимир Мельник, DataArt
"Up-Down Development & DSL-first approach", Владимир Мельник, DataArt
 
Clean architecture with asp.net core
Clean architecture with asp.net coreClean architecture with asp.net core
Clean architecture with asp.net core
 
[2017/2018] Introduction to Software Architecture
[2017/2018] Introduction to Software Architecture[2017/2018] Introduction to Software Architecture
[2017/2018] Introduction to Software Architecture
 
Multi-tenancy with Rails
Multi-tenancy with RailsMulti-tenancy with Rails
Multi-tenancy with Rails
 
Modern Database Development Oow2008 Lucas Jellema
Modern Database Development Oow2008 Lucas JellemaModern Database Development Oow2008 Lucas Jellema
Modern Database Development Oow2008 Lucas Jellema
 
Understanding angular js
Understanding angular jsUnderstanding angular js
Understanding angular js
 
Struts Ppt 1
Struts Ppt 1Struts Ppt 1
Struts Ppt 1
 
Requirements engineering in agile
Requirements engineering in agileRequirements engineering in agile
Requirements engineering in agile
 
OORPT Dynamic Analysis
OORPT Dynamic AnalysisOORPT Dynamic Analysis
OORPT Dynamic Analysis
 
[2016/2017] Introduction to Software Architecture
[2016/2017] Introduction to Software Architecture[2016/2017] Introduction to Software Architecture
[2016/2017] Introduction to Software Architecture
 
L19 Application Architecture
L19 Application ArchitectureL19 Application Architecture
L19 Application Architecture
 

Último

renewable energy renewable energy renewable energy renewable energy
renewable energy renewable energy renewable energy  renewable energyrenewable energy renewable energy renewable energy  renewable energy
renewable energy renewable energy renewable energy renewable energyjeyasrig
 
MUT4SLX: Extensions for Mutation Testing of Stateflow Models
MUT4SLX: Extensions for Mutation Testing of Stateflow ModelsMUT4SLX: Extensions for Mutation Testing of Stateflow Models
MUT4SLX: Extensions for Mutation Testing of Stateflow ModelsUniversity of Antwerp
 
8 Steps to Build a LangChain RAG Chatbot.
8 Steps to Build a LangChain RAG Chatbot.8 Steps to Build a LangChain RAG Chatbot.
8 Steps to Build a LangChain RAG Chatbot.Ritesh Kanjee
 
Technical improvements. Reasons. Methods. Estimations. CJ
Technical improvements.  Reasons. Methods. Estimations. CJTechnical improvements.  Reasons. Methods. Estimations. CJ
Technical improvements. Reasons. Methods. Estimations. CJpolinaucc
 
MinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
MinionLabs_Mr. Gokul Srinivas_Young EntrepreneurMinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
MinionLabs_Mr. Gokul Srinivas_Young EntrepreneurPriyadarshini T
 
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdfFlutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdfMind IT Systems
 
openEuler Community Overview - a presentation showing the current scale
openEuler Community Overview - a presentation showing the current scaleopenEuler Community Overview - a presentation showing the current scale
openEuler Community Overview - a presentation showing the current scaleShane Coughlan
 
If your code could speak, what would it tell you? Let GitHub Copilot Chat hel...
If your code could speak, what would it tell you? Let GitHub Copilot Chat hel...If your code could speak, what would it tell you? Let GitHub Copilot Chat hel...
If your code could speak, what would it tell you? Let GitHub Copilot Chat hel...Maxim Salnikov
 
Telebu Social -Whatsapp Business API : Mastering Omnichannel Business Communi...
Telebu Social -Whatsapp Business API : Mastering Omnichannel Business Communi...Telebu Social -Whatsapp Business API : Mastering Omnichannel Business Communi...
Telebu Social -Whatsapp Business API : Mastering Omnichannel Business Communi...telebusocialmarketin
 
8 key point on optimizing web hosting services in your business.pdf
8 key point on optimizing web hosting services in your business.pdf8 key point on optimizing web hosting services in your business.pdf
8 key point on optimizing web hosting services in your business.pdfOffsiteNOC
 
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...jackiepotts6
 
Enterprise Content Managements Solutions
Enterprise Content Managements SolutionsEnterprise Content Managements Solutions
Enterprise Content Managements SolutionsIQBG inc
 
Unlocking the Power of IoT: A comprehensive approach to real-time insights
Unlocking the Power of IoT: A comprehensive approach to real-time insightsUnlocking the Power of IoT: A comprehensive approach to real-time insights
Unlocking the Power of IoT: A comprehensive approach to real-time insightsconfluent
 
Mobile App Development process | Expert Tips
Mobile App Development process | Expert TipsMobile App Development process | Expert Tips
Mobile App Development process | Expert Tipsmichealwillson701
 
Einstein Copilot Conversational AI for your CRM.pdf
Einstein Copilot Conversational AI for your CRM.pdfEinstein Copilot Conversational AI for your CRM.pdf
Einstein Copilot Conversational AI for your CRM.pdfCloudMetic
 
VuNet software organisation powerpoint deck
VuNet software organisation powerpoint deckVuNet software organisation powerpoint deck
VuNet software organisation powerpoint deckNaval Singh
 
Revolutionize Your Field Service Management with FSM Grid
Revolutionize Your Field Service Management with FSM GridRevolutionize Your Field Service Management with FSM Grid
Revolutionize Your Field Service Management with FSM GridMathew Thomas
 
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...MyFAA
 
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptxCYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptxBarakaMuyengi
 
BATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data MeshBATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data MeshBATbern
 

Último (20)

renewable energy renewable energy renewable energy renewable energy
renewable energy renewable energy renewable energy  renewable energyrenewable energy renewable energy renewable energy  renewable energy
renewable energy renewable energy renewable energy renewable energy
 
MUT4SLX: Extensions for Mutation Testing of Stateflow Models
MUT4SLX: Extensions for Mutation Testing of Stateflow ModelsMUT4SLX: Extensions for Mutation Testing of Stateflow Models
MUT4SLX: Extensions for Mutation Testing of Stateflow Models
 
8 Steps to Build a LangChain RAG Chatbot.
8 Steps to Build a LangChain RAG Chatbot.8 Steps to Build a LangChain RAG Chatbot.
8 Steps to Build a LangChain RAG Chatbot.
 
Technical improvements. Reasons. Methods. Estimations. CJ
Technical improvements.  Reasons. Methods. Estimations. CJTechnical improvements.  Reasons. Methods. Estimations. CJ
Technical improvements. Reasons. Methods. Estimations. CJ
 
MinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
MinionLabs_Mr. Gokul Srinivas_Young EntrepreneurMinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
MinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
 
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdfFlutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
 
openEuler Community Overview - a presentation showing the current scale
openEuler Community Overview - a presentation showing the current scaleopenEuler Community Overview - a presentation showing the current scale
openEuler Community Overview - a presentation showing the current scale
 
If your code could speak, what would it tell you? Let GitHub Copilot Chat hel...
If your code could speak, what would it tell you? Let GitHub Copilot Chat hel...If your code could speak, what would it tell you? Let GitHub Copilot Chat hel...
If your code could speak, what would it tell you? Let GitHub Copilot Chat hel...
 
Telebu Social -Whatsapp Business API : Mastering Omnichannel Business Communi...
Telebu Social -Whatsapp Business API : Mastering Omnichannel Business Communi...Telebu Social -Whatsapp Business API : Mastering Omnichannel Business Communi...
Telebu Social -Whatsapp Business API : Mastering Omnichannel Business Communi...
 
8 key point on optimizing web hosting services in your business.pdf
8 key point on optimizing web hosting services in your business.pdf8 key point on optimizing web hosting services in your business.pdf
8 key point on optimizing web hosting services in your business.pdf
 
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
 
Enterprise Content Managements Solutions
Enterprise Content Managements SolutionsEnterprise Content Managements Solutions
Enterprise Content Managements Solutions
 
Unlocking the Power of IoT: A comprehensive approach to real-time insights
Unlocking the Power of IoT: A comprehensive approach to real-time insightsUnlocking the Power of IoT: A comprehensive approach to real-time insights
Unlocking the Power of IoT: A comprehensive approach to real-time insights
 
Mobile App Development process | Expert Tips
Mobile App Development process | Expert TipsMobile App Development process | Expert Tips
Mobile App Development process | Expert Tips
 
Einstein Copilot Conversational AI for your CRM.pdf
Einstein Copilot Conversational AI for your CRM.pdfEinstein Copilot Conversational AI for your CRM.pdf
Einstein Copilot Conversational AI for your CRM.pdf
 
VuNet software organisation powerpoint deck
VuNet software organisation powerpoint deckVuNet software organisation powerpoint deck
VuNet software organisation powerpoint deck
 
Revolutionize Your Field Service Management with FSM Grid
Revolutionize Your Field Service Management with FSM GridRevolutionize Your Field Service Management with FSM Grid
Revolutionize Your Field Service Management with FSM Grid
 
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
 
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptxCYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
 
BATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data MeshBATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data Mesh
 

Crafted Design - ITAKE 2014

  • 3.  What is this application about?  What are the main concepts?  What does this application do?  What are the main features?  Where do I need to change?  Where do I put a new feature?
  • 4.  Looking from above, I can’t see what the application does or is about  Architectural and design concepts mixed with domain  Badly structured packages/namespaces  I don’t know where to start  Classes and methods are too low level
  • 9. MVC & MVC Variations • MVC (Smalltalk 76/80) • MVC (general concept – 1988) • Three-Tier Architecture (Presentation, Logic, Data) • MVC (Model 1/Model 2) • Model View Adapter (MVA) • Model View Presenter (MVP) • Model View ViewModel (MVVM) • Presentation-Abstraction-Control (PAC) • ….
  • 11. MVC & MVC Variations They are all right. And they are wrong. It all depends on the ‘V’iew.
  • 12. Views impact MVC structure Depending on the view technology, Views and Controllers responsibility becomes more/less coupled or blurred.  Web applications  Single-page AJAX applications with stateless backend  Console-based applications  Desktop applications  Games  Mobile / tablets  External systems (talking via Queues / Webservices) However, the model should remain unchanged.
  • 13. MVC – A Macro Organisational Pattern Model V C M Delivery Mechanism
  • 14. “Model” is overloaded and confusing  Model (M in MVC)  Domain Model (DDD)  View Model  Data Model  Entities & Active Record  and other artificial definitions from MVC frameworks  Associated with the persistence mechanism?
  • 15. M => Domain Model (DDD) Domain Model combines state and behaviour, with more focus on the latter. DDD define a few building blocks to your domain:  Entities  Value Objects  Factories  Repositories  Services  Application  Domain  Infrastructure  Aggregates
  • 16. << Web app >> Embedded Domain Model Model V C DM Delivery Mechanism Infrastructure Infrastructure DB Queue
  • 17. Deployable Domain Model Delivery Mechanisms << external system >> << mobile app >> DB << deployable app >> Model Infrastructure DM<<W/S>> <<W/S>>
  • 18. Event-Driven Domain Model Delivery Mechanisms DB Queue << external app 2 >> << external app 1 >> << deployable app >> Model Infrastructure DMQueue <<event 1>> <<event 2>>
  • 19. Domain Model building blocks & responsibilities A = Action, DS = Domain Service, S = Infra. Service, R = Repository Model A 1 R 3 DS 1 DS 3 R 1 S Infrastructure Impl DM DS 2 Impl A 2 << web app >>
  • 20. Behaviour: Action, Domain Service or Entity? Domain Service Entity Action Defines the action our domain model will be asked to perform. Behaviour related to multiple instances of the same entity or different entities. Behaviour that doesn’t fit any specific entity. Behaviour related to the data of a single instance of an entity
  • 21. Repositories (not DAOs) Model <<repository>> Library <<repository>> Users Infrastructure <<Mongo>> Books Domain Model <<Oracle>> Users “A Repository represents all objects of a certain type as a conceptual set. It acts like a collection, except with more elaborate querying capability.” ~ Eric Evans
  • 22. An example would be good… Order Service Orders <<interface>> Card Processor Payment ValidatorMake Payment User Account Service Usersvalid account? Payment Gatewaypay has prime account? process card validate store order Action Domain Service Infra. Service Repository Class <<interface>> Email Sender email confirmation
  • 23. Class responsibility C A DS R cl Input Output End of code branch Produces the output End of flow First to handle input Start of the flow Execution Flow  Closer to the input: Control flow, higher level abstraction, detailed work is delegated (e.g. ProcessTrade (A), MakePayment (A)) — More suitable for Outside-In TDD (mockist).  Closer to the output / end of branch: Specific and detailed behaviour, no delegation, lower level abstraction (e.g. Parse XML (Parser), Create User (Repository)) Domain Model entry point Domain Concept entry point
  • 24. Domain Model collaborations guideline C1 A 1 A 2 DS 1 DS 4 DS 3 R 4 R 1 cl cl cl cl C = Controller, A = Action, DS = Domain Service, R = Repository, cl = class DS 2 X A 3 R 5XC2 Except for read model X
  • 25. Command & Query Actions << web app >> Model R DS <<Write Model>> A Model <<Read Model>> A R DB DB Queue <<domain events>>
  • 26. So, how does the app structure look like?
  • 27. Web project responsibility Control flow (invoke actions) JSON / XML parsers or converters View Models, validators, etc Static files Delivery Mechanism: Defines the user journey
  • 28. Core responsibility (simple project) Tells what the system is about Tells what the system does
  • 29. Core responsibility (bigger project) Epic / Theme Epic / Theme Epic / Theme Related domain concepts
  • 30. What is inside model packages? Aggregate root (entity) Repository Entity (part of Book aggregate) Domain Service Value Object (part of Book aggregate) Part of aggregate behaviour Repository Value Object (part of User aggregate) Aggregate root (entity) Domain Service
  • 31. What is inside infrastructure? Interfaces defined by the domain. Dependency Inversion Principle (DIP) CreditCardProcessor implementations Repository implementations
  • 32. Defining testing strategies and boundaries • Unit • Integration • Acceptance • Journey • Black box • Component • System • Functional • Alpha • Beta • Conformance • … Types of tests
  • 33. Testing strategies: User Journey Model A 1 DM A 2 << web app >> A 1 A 2 Tests the journey a user will have to do something useful in the system Application is tested as a black box normally using a BDD framework Actions are faked. We just want to know if the application presents the user with the correct journey Designed according to User Stories and Features <<fake>> <<fake>>
  • 34. Infrastructure Impl Testing strategies: Acceptance (Action / Behavioural) A DS 1 <<mock>> RDS 2 R Tests a behaviour (action) provided by the system Action is the entry point and all external dependencies are stubbed Domain Model Normally tested using a BDD framework
  • 35. Testing strategies: Integration Tests the classes at the system boundaries Infrastructure Impl A DS 1 <<mock>> RDS 2 R Domain Model Normally done using an in- memory Database using a unit testing framework
  • 36. Testing strategies: Unit (Class level) Unit test at class/method level Infrastructure Impl A DS 1 RRDS 2 Domain Model DS 1 DS 2 All collaborators are mocked / stubbed (spies)
  • 37. Testing strategies: End-to-End Model A 1 R 3 DS 1 DS 3 R 1 S Infrastructure Impl DM DS 2 Impl A 2 << web app >> Full application deployed Uses BDD framework, accessing a testing database and fake external dependencies Very few tests at this level, just to make sure application is wired properly
  • 38. Interaction-Driven Design – IDD (Outside-In design) C A DS R cl Input Output Execution Flow  Starting from the action, model the expected behaviour (outside-in)  Entities (data structures) will emerge in order to satisfy the behaviour  Focus is on the behaviour of the system and not on how data is stored/related Design Flow
  • 39. Answering the two original questions  What is the application about? (main concepts)  What does the application do? (main features) Expressed by nouns Expressed by verbs (Actions)

Hinweis der Redaktion

  1. Disclaimer This is still a work in progress
  2. For years I’ve been trying to find ways to, while looking from above, answer the following questions:
  3. Looking from above: controllers, repositories, managers, services, etc. Layers vs. domain? How do they fit together? How many of you are happy with your package structure?
  4. Confusing. I have no idea what this application is about or what it does. What does this application do? What is it about?
  5. Gives me some information on what the application is about but not what it does. Loads of duplication Very poluted Books and Users. Cool, but what does this application do?
  6. Once again, gives me no information on what the application is about or what it does. But I know it is a web app though. Sigh. Awesome. It’s a web application. So?
  7. So, how do I solve the problem? How do I answer the questions? But first things first… Before getting into how I’m organising/structuring my code, we need some background to justify my decisions
  8. It was only later, in a 1988 article in Glenn E. Krasner and Stephen T. Pope that MVC was expressed as general concept, in the The Journal of Object Technology
  9. Anaemic Domain: Model is only composed by entities and data representation Fat Controllers: Without a place to put business logic, the logic is put on the controllers
  10. They are all wrong, but they are all right. It all depends on the view.
  11. What should we have in the model? What is model?
  12. Domain Model embedded in a Web Application V/C belong to the application (main)
  13. Domain Model wrapped in a deployable application Expose a W/S for mobile apps / Web apps / External Systems This is similar to Hexagonal Architecture (Ports & Adapters belong to Infrastructure) Mobile app could have the V/C
  14. Event-Driven application
  15. - Actions are the entry point to the domain model (control flow delegating to Domain Services) - Actions can use factories to create domain objects according to the input (normally not in the domain format) - Domain Services are the entry point to a domain concept. Repositories are helpers to the Domain Service and should not be exposed.
  16. - I name repositories using the plural (collection) of the domain concept they represent (Users, Books) Repository vs. DAO (Former behaves as a collection. Latter is a pattern to access data) Data Access Object (DAO) is a commonly used pattern to persist entities (data) into a database. (CRUD)
  17. Classes closer to the output are more suitable for Classic TDD, unless they are close to the boundaries (that need to be mocked in both TDD styles)
  18. Controller can talk to one or more than one action UC can talk to one or more DS or classes DS can talk to other DS or Infra Service Repositories are never exposed. Just accessed by its own DS. Exception is on Read Model
  19. - Write model throws domain events Query model listens to domain events and populate “read” DB Query UC return data according to the application needs (Report, Complex Screen with denormalised data, etc) Command Actions go though the domain model, delegating to domain services Query Actions may go to a read model instead, querying with joins returning VOs that are specific to the UI. No need to organise them in different packages (using command & query as names)
  20. Controllers talk the Actions Controllers should be thin, invoking an action, and choosing the view to be displayed (maybe creating page objects or converting to JSON?) web: View (page objects) Web: Infrastructure (JSON / XML parsers or converters)
  21. Controllers talk the Actions Controllers should be thin, invoking an action, and choosing the view to be displayed (maybe creating page objects or converting to JSON?) web: View (page objects) Web: Infrastructure (JSON / XML parsers or converters)
  22. In a simple project (CRUD), action may be as simple as Insert, Delete, Update User Not all action se cases have a direct correlation to entities (AddBookToWishList)
  23. MakePayment UC does not need to have a related Entity, neither FindRecommendations. MakePayment may sent information out to a different system FindRecommendations may return a list of products (after a very complicated logic, taking to consideration user attributes and buying patterns)
  24. Many of the DDD building blocks
  25. Decouples the architectural decisions and layers from the domain model.
  26. First, discuss with your team and define the scope of each test Then, chose a name for each scope
  27. Mocking the backend makes these tests run really fast and predictable. Easy to setup
  28. Tests multiple classes together. External dependencies are stubbed
  29. Tests multiple classes together. External dependencies are stubbed
  30. Tests multiple classes together. External dependencies are stubbed
  31. Unit (class / method level) Acceptance (through action, in-memory/mocked DB/infrastructure) Integration (via the boundaries, in-memory DB) User Journey (Via the UI – mocking action) End-to-end (black box, very few, just sunny day scenario) The closer to the input a class is, the more flow control and delegation it does. The closer to the output a class is, the more specific and less delegation it does.
  32. A class API (public interface) should be designed from the client’s perspective. Doing otherwise leads to over-engineering and YAGNI – You Ain’t Gonna Need It Businesses are not interested in how data is stored or related. They are interested in the behaviour of the software.