Embed Size (px)
DESCRIPTION
(IMPROVED VERSION FROM GEECON) How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features? Purely looking at unit tests is either not possible or too painful. Looking at higher-level tests can take a long time and still not give us the answers we need. For years, we have all struggled to design and structure projects that reflect the business domain. In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing. By iteratively modifying the project structure to better model the application requirements, he has come up with a design style that helps developers create maintainable and domain-oriented software.
Citation preview
Crafted Design
Sandro Mancuso@sandromancusohttp://leanpub.com/socra
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
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 Controller
s
Coupling with MVC framewor
k
MVC & MVC Variations
They are all right. And they are wrong. It all depends on the ‘V’iew.
Views impact MVC structureDepending 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
?
DeliveryMechanism
“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
ModelV C DM
DeliveryMechanism
Infrastructure Infrastructure
DBQueue
Deployable Domain Model
DeliveryMechanisms
<< external system >>
<< mobile app >>
DB
<< deployable app >>
Model
Infrastructure
DM<<W/S>>
<<W/S>>
Event-Driven Domain Model
DeliveryMechanisms 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…
OrderService Orders
<<interface>>Card Processor
PaymentValidatorMake
Payment
User AccountService 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 outputEnd of flow
First to handle inputStart 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 2X
A 3 R 5XC2 Except for read model
X
Command & Query Actions
<< web app >>
Model
RDS
<<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: IntegrationTests 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 2All 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
