no more three tier - a path to a better code for cloud and azure
TRANSCRIPT
No more Three TierA path to a better code for Cloud and Azure
Marco Parenzan
TSAIM13 Edition [Fall 2014]
CODE
Code can be found in
https://github.com/marcoparenzan/TSAIM2013-Core
Marco ParenzanFormazione & Divulgazione con 1nn0va
Microsoft MVP 2014 for Microsoft Azure
Formazione & Progettazione con ITS Kennedy
Ricerca e Innovazione con Servizi Cgn
www.slideshare.net/marco.parenzan
marco [dot] parenzan [at] libero/live [dot] it
www.innovazionefvg.net
Developer e Architect in .NET e Web
Cloud Developer
Loves functional programming
Some videogames for fun
It’s all about responsibility
In code
RESPONSIBILITY
is implemented with
encapsulation
How ENCAPSULATION is implemented in
code?
With Functions
With Classes and Objects
With Interfaces
Three tier
a model for modular solutions
n-Tier
A tier is a responsibility container
Tiers are «stacked»
A tier communicate with two layers, at most!
Tier-2
Tier-1
Tier-n
…
n-Tier
A tier is a responsibility container
Tiers are «stacked»
A tier communicate with two layers, at most!
Ok, not always true
Tier-2
Tier-1
Tier-n
…
Three Tier
Three is the most famous standard
n-Tier configuration
How do tiers communicate each other?
Define responsibility between layers
Have responsibility for «lower» layer
Consume responsibility by «top» layer
Business Logic
Data Access
PresentationData
Interfaces == Contract
Contract: agreement between parts
Define:
How are you talking (Interface)
Interface=Sentence
What are you talking about (Model)
Model==Words
Contract==Interfaces
Model
Contracts and Development Teams
«Three» teams can develop independently, if they agree
on Contracts
Contract DA/BL
Contract BL/P
Interfaces and Layers
Layers communicate each other via
contracts/interfacesBusiness Logic
Data Access
Presentation
Contract DA/BL
Contract BL/P
…MEANWHILE, IN THE SQL ROOM…
Database (First)
Database is analysis
Database is «contract»
We’ll speak about with #DDD
Up to now, this is a common assumption
https://speakerdeck.com/manuelscapolan/the-role-of-the-database-in-a-domain-driven-design-world
Scaffolding
http://en.wikipedia.org/wiki/Scaffold_(programming)
…because DB tells you everything
… generate the final code that the application can use
to create, read, update and delete database entries…
It creates a model (an abstraction for table) and a Data
Access (an abstraction for Database)
Data Session
Model
Database First Three Tier
When we put togeter Three Tier and Scaffolding, we
tipically forget (or confuse) Model with Contract
Model is part of the Contract
Data Access is not a contract, but only operations on
data
We can only accept, not agreeBusiness Logic
Data Access
Presentation
Mo
de
l
MVC
MVC Database First Three Tier
Modern Web Presentation is Model ViewController
Controller is coordination in Presentation
View is Output Template
Model is…the same DB model…AAARRRGGGHHH!!!!
This is a common mistake
Not the rule of MVC
There is a problem with terms (Model, VIEWmodel, Data Transfer Objects, etc…)
Model because of «modeling» activity, notmodel from DB!
Business Logic
Data Access
Controller
View
Mo
de
l
MVC
Scaffolded MVC
Database First Three Tier
Put all togheter
+ Database First
+ Scaffolding
+ Three Tier
+ MVC
+ (-Business Logic)
= Real bomb!
Data Session
Controller
View
Business Logic
Mo
de
l
Some common mistakes in
scaffolding template
Scaffolding Scenario
“Build model from metadata”
You model classes from Database
You model classes for storage (Entity)
Classes as Aggregate of data by ownership
You decide queries during development
Entity is atomic
All or nothing
Mistake #1: No encapsulation
No responsibility
Pay attention on code you change.
Your change can have effectes on others…
Manteinance penalty
Cost
Bugs
Mistake #2: No scalability
OK it can scale...
…but are you free to choose?
(RDBMS) Database First is a costraint
Vertical scalability as the only opportunity
Horizontal scalability is no more an opportunity
Performance penalties
Speed
Money
Mistake #3: Modeling, not Model!
Model in MVC is the result of a modeling activity, not a model from OR/M!
There are many models types
View Models
Domain Models
Anemic Models
…
DB is not a contract
Mistake #4: one model does not fits for all
Foremost, Model is «stretched» as contract between all tiers
Because it’s DATABASE model, not BUSINESS model
One model for DYNAMIC queries
Because you don’t know which queries you need
No queries in analisys
A road to a (more) modern model
Presentation has its own model
No more ONE model
Presentation models
“Create/Read/Update/Delete model”
You model classes from Scenarios
You model classes for view (ViewModel)
You can decide queries during development
Mapping is a valuable costing
ViewModel is atomic
ViewModel map to some part of an entity
ViewModel
Is a model of an entity optimized for UI
No Database-like references
An entity object is not suitable for universal usage
No localization
Data already decoded
Data already loaded (if good to)
A ViewModel is typically an “pure” “language” object
Minimize (down to zero) needs of getting other data from other sources
Queries in analysis
Define ViewModels in analysis
All data required are in analysis
You identify queries needed to map data from/to database
You start identifying tests
Pro & Cons….Cons?
In a ViewModel you have “parts” of a Database model
You can have MANY viewModels that corresponds to a single Database Model
Is this a cons? No
Cons
Many, not one
Slow…more to code
Pro
More testable
Fast…code at runtime
A road to a (more) modern model
A lap around CQRS
Decide what you need to do
Don’t make implicit choices
Don’t choose for others
Pretend to know what they need to do
Decide what you want to do then
It’s your intention
You decide an action to do
That’s action is composing a command
Send you command
Command object is a object that assert an intention to an action
All values assigned to properties specify parameters of the intention of the command
Typically, this kind of objects are flat (not complex)
Typically this object have no particular dependencies
Don’t expect immediate execution
Ccommand can be queued
Data Transfer Object - DTO
An object that carries data between processes in order to reduce the number of method
calls (http://martinfowler.com/eaaCatalog/dataTransferObject.html)
An aggregate of information
A mono-directional object optimized for data presentation
Typically is a result of mapping of a generic query from a datasource
Recap CQRS Scenario
“Command/Query Responsibility Segregation”
You model classes from requests and responses
You model classes for actions (Commands) and queries
Classes as aggregates of parameters (Commands) and aggregates of values (Data
Transfer Objects)
You need to decide queries during development, because Model can be huge
Command is atomic, DTO is atomic
ViewModel work to
CQRS defined
CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young
At its heart is a simple notion that you can use a different model to update information than the model you use to read information
This simple notion leads to some profound consequences for the design of information systems.
From Martin Fowler
http://martinfowler.com/bliki/CQRS.html
Comparing Application Scenarios
Scaffolding View Models CQRS
Development Time
(perceived, initially)
Low Average High
Development Cost
(to long)
High Average Average
Complexity High Average Low
Testability Low Average High
Overall Quality Low Average High
Model costs
0
100
200
300
400
500
600
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Scaffolding
ViewModels
CRUD
CQRS cost is substantially
costant through the
implementation of the entire
loop
Evaluating Application Scenarios
Founding Principles
Application Lifecycle Management
Scrum
Maintainable Code
Parameters
Development Cost (perceived, initially)
Development Cost (to long)
Complexity
Testability
Overall Quality
Scalability
Scenarios
Scalability
From Wikipedia
Scalability is the ability of a system, network, or process to handle a growing amount of work in a
capable manner or its ability to be enlarged to accommodate that growth
In another way
Scalability describes the ability to keep constant the handling time of a request as amount of
work growth.
Ways to manage scalability
Scaling Up
Get it bigger
Be carefull about single points of failure
Scaling Out
Get it more that one
Be careful about state
Async
Give it the right time
Decoupling in time
Queuing
Decoupling in tiers
Managing demand
Don’t forget you are also paying for unnecessary software licencing while you are over capacity
TIME
IT C
AP
AC
ITY
Actual Load
Allocated
IT-capacities
Too Much
Power
Load Forecast
Potential business loss
Wasted capacity
Not Enough Power
Predictable Bursting
Services with no seasonality trends
No particular peaks
IT complexity, no wasted capacity
Uso «sostanzialmente» costante
Applicazioni interne
Unpredictable Bursting
Marketing On-Time Offer
Aperiodical Dues
Special Event
Unexpected/unplanned peak in demand
Sudden spike impacts performance
Can’t over provision for extreme cases
Average Usage
Periodical Bursting
Marketing Periodical Offer
Periodical Dues
Special Repeatable Events
Services with micro seasonality trends
Peaks due to periodic increased demand
IT complexity and wasted capacity
On/Off Bursting
Digital media rendering and encoding
Financial and insurance risk calculation
Engineering modeling and simulation
Computational life sciences
Earth sciences
Data analytics
On & off workloads (e.g. batch job)
Over provisioned capacity is wasted
Time to market can be cumbersome
Growing Fast
Social Media
Web Games
Successful services needs to grow/scale
Keeping up w/ growth is big IT challenge
Cannot provision hardware fast enough
Average Usage
Scaling
Scale up by choosing different VM sizes
Scale out by adding more instances
Scale-out automatically with Elastic scaling
Scale out static content with CDN to distribute user traffic
Scale out low-variable data with caching to offset server workloads
Async to scale?
It depends…
(A)Syncronous
Syncronous (relation) between a client and a server is when server MUST respond to client
request and client have to wait ACTIVELY for server response.
Asyncronous, in a web context has two situations
Client SideAsyncronous is for responsiveness
Server SideAsyncronous is for scalability
Responsiveness
Don’t block UI thread so user can continue interacting with app while request is currently running
Scalability
Increase the usage of the thread pool while a request is blocked for I/O
“Async” scale-up
Sync cause “scaling up”
You can only increase resources because “sync” scenario tends to “lock” resources
Async lower the need of scaling up
Resources are better used
Async is not useful to scale out
A queue to scale
Let command be executed to whom is
really responsible
Async client
Responsive
Async server (MVC action)
Scalable
‘Still synchronous when executed by MVC role
MVC is “front end” role to the client
Syncronous implies “give a response”
Really?
It’s really needed
Response vs. “acknowledge”
Syncronization is needed to obtain an answer
What’s in the answer?
Result
Acknowledge
Result
What you expected from execution of the request
Acknowledge
Response about “taking responsibility” on request, but not the result
Why not the result
Typically because it take too long to obtain response
Async (client/server) is always “pretend an answer” inside a timeout ….in seconds on average
Many scenarios cannot have this
Order management
Interop with legacy systems
…
Command as a serializable request
Command is the metaphor for the request
Useful to be serializable
Serializable is useful to store/persist/”suspend”
Why “suspend”?
Because a long time to execute
Executor is overloaded
Executor is doing something else
Executor need it’s time to execute
Where serializing?
Somewhere where “taking out” is a principle
For example “FIFO” structures: queues
Using Queues
Queue are useful to receive commands
MVP frontend role just acquire commands
Commands are syntactically validated
Commands are just queued
(a)sync response from frontend is quick
Just acknowledge the insertion of command into
queue
MVC
Frontend
Role
Controller
ActionCommand Command
Co
mm
an
d
Co
mm
an
d
Co
mm
an
d
Co
mm
an
d
Co
mm
an
d
Co
mm
an
d
Command Queue
A worker to scale
Commands in a queue
When Commands are in queue, who take commands out?
Command Handler is the generic concept
A CH handle a command
Many commandsmany command handlers
Domain in the CH
Command Handlers execute command
Act on the domain
Call aggregate entity methods
Mapping command parameters
Typically Commands are not domain objects
Workers
A command handler must be hosted in a process
Process are typically NON-UI processes
simple, Light
end-less (infinite loop)
Sleepy (suspend themselves each loop)
Stateless (no global variables, just loop function)
Horizontally scalable (execute many in parallel, in the same machine, in many machines)
Typically Console.exe apps (in .NET)
Estract message from queue and execute it
Support
Retry logic
Priority logic
An event to scale
Don’t take more responsibility: inform
about what you have done
A worker is the identity that implements CH and act on then domain
A worker knows the domain through aggregates
Aggregate know only its domain
What about impacts about acting on the domain?
Copies of data somewhere else
Perform other actions into other domain
Have the aggregate knowledge about effected?
No
Aggregate must declare that Something has happened
An event
An event is the knowledge of something happened in the history
An event must be shared with anyone
…interested about event
Event queue
Events generated by aggregate must be
collected in a structure that shares event
to many
Publisher/subscriber pattern
Many listener “subscriibe” to the event
queue
A subscriber declare which messages are
interesting
Aggregate
Method
1 Event
Ev
en
t
Ev
en
t
Ev
en
t
Ev
en
t
Ev
en
t
Ev
en
t
Event Queue
Listener
Listener
Listener
Listener
Push data on the web
Responses: where are they
Client have done a request/a command
Client have received an acknowledge
Domain has executed the command
A result have happened…yes….?!?!?!?
A result is the execution of the command
A result is found
When? When event is notified
Where? Event give all and enough information to RETRIEVE the result, not the result itself
Client knows following the event which is the result to be retrieved
Pull/Push communication with client
How client knows about events?
Pull way
Client request from an event queue if it have and event
Events must be stored
Client have to query events queue to check if there are some new events
Push way
Server will reach client and send it an event message
Modern way with Web Sockets (in a Web scenario)
SignalR in ASP.NET
Retrieve the result
Event contains information to retrieve the result, not the result itself
Some keys, ids
Some display data
Event is a DTO
Event is enough to get other DTOs, for example
Event can be used to trigger other actions
No more Three TierA path to a better code for Cloud and Azure
Marco Parenzan
TSAIM13 Edition [Fall 2014]