Transcript Kein Folientitel

DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
Domain-Driven
Development
An introduction
Markus Völter
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
-1-
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
About me
•
•
Independent Consultant
•
Focus on
• Software Architecture
• Middleware
• Model-Driven Software
Development
Markus Völter
[email protected]
www.voelter.de
Based out of Heidenheim,
Germany
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
-2-
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
Domain Driven Development
•
Domain Driven Development is about making software
development more domain-related as opposed to
computing related. It is also about making software
development in a certain domain more efficient.
Domain Concepts
Domain Concepts
mental work
of developers
Software Technology
Concepts
ingenieurbüro für softwaretechnologie
Software Technology
Concepts
w w. w .voelter .de
-3-
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
Reasons for DDD
•
Software Development is too complex and too
expensive (now, this is a really new finding ) …
… because:
• There is too little reuse
• Technology changes faster than developers can learn
• Knowledge and practices are hardly captured explicitly
and made available for reuse
• Domain experts cannot understand all the technology
stuff involved in software development
•
DDD aims at attacking some of these problems.
We shall see how on the following slides.
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
-4-
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
What is a „Domain“
•
A definition could be:
A domain is a bounded area
of knowledge or interest.
•
Examples (from the world of Software) include:
• eBanking
• Embedded Software
• Web-Based eBusiness Applications
• Control Software for 4-Cylinder Diesel Engines
• Astronomical Image Processing Software
•
Domains can have varios „scopes“ as well as various
„flavours“ – see next slides.
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
-5-
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
Hierarchical Structuring of Domains
•
Since Domains can be of any size or granularity, it is
useful to structure domains hierarchically.
•
Automotive Example:
Automotive
Systems
Embedded
Systems
•
eBanking Example:
Engine Controllers
Diesel
Gasoline
4-Cyl
web-based
e-Banking
money
transfer
inv.
bank.
eBusiness
Apps
Rich
Clients
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
-6-
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
„Kinds“ of Domains
•
In the context of software development it is also useful to
distinguish (at least) two kinds of domains:
• Technical Domains adress key technical issues related
to software development such as
• Distribution, Failover and Load-Balancin
• Persistence and Transactions
• GUI Design
• Concurreny and Realtime
• Functional Domains represent the business/professional
issues; examples include
• Banking
• Human resource management
• Insurance
• Engine Controllers
• Astronomical Telescope Control
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
-7-
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
Domains in a Software System
Communication
Session Handling
Multi-User/
Concurrency
GUI
As a consequence of the classifications on the previous
slides, a software system typically consists of several
domains:
Persistence
•
eBusiness
System
Web Shop
Payment
Catalogue
Cross Selling
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
-8-
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
Reuse in the context of these domains
•
Key to more efficient software development is to aim at
systematic reuse in each of these domains.
(see also Software System Families
and Product Line Engineering)
•
Traditionally, this reuse can contain
• Knowledge
• Best Practices
• Patterns
• Artifacts
• Libraries
• Platforms
• Components
• Aspects
• Middleware
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
-9-
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
Reuse in the context of these domains – Building Systems
•
In order to allow for reuse of software artifacts, these
have to
• be self-contained
• have minimal overlap to other artifacts
• ideally represent only one concerns (in the sense of AOP)
• adaptable to a reasonable degree
• easy to use, automating repetitive tasks
•
In short: they need to have a certain quality – they are
software development assets.
•
Building a system then involves composing suitable
artifacts from the different domains to a coherent
application.
•
Often, certain (domain-specific) tools will be required
to achieve this, such as DSL editors & generators or
aspect weavers
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 10 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
Reuse of the infrastructure
•
So: you don‘t just reuse finished software building blocks;
rather you also reuse the infrastructure to build the
software.
• This specifically includes modelling tools, build
environments, generators, weavers, etc.
•
DDD is thus about building an infrastructure for
efficient software development in a certain domain.
• Thus, this requires to some extend building your own tools
– you might have to deviate from standards (e.g. not use
UML for modelling).
•
For reasons of economy, this is especially useful in the
context of Product Line Engineering and Software
System Families.
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 11 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – Focus on Good Architecture
•
In order to reuse any software artifact, it must
• have a clear underlying structure
• have a well-defined interfaces and context dependencies
• have a clearly defined responsibility
• be maintainble and extendable
• and satisfy performance considerations
•
In one word, the architecture of the artifacts must be
solid. It is a good idea to build it upon well-proven
architectural patterns.
•
This is also true for the applications built from these
artifacts.
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 12 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – Expressive Code
•
As advertised by the Agile folks, code should be readable
like prose text (for those who understand the language).
•
This requires that the core concepts, constraints and
processes of a domain are suitable represented by the
code.
•
•
As a consequence the program
can to some extend directly
represent the domain
knowledge, as opposed to
being a cluttered piece of
„just implementation“.
This requires a good code
structure, and to some extend
wrapping the underlying base
technology.
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
Applications
Domain
Platform
- Core Entities
- Core Valuetypes
- Business Rules
- Business Services
Technical
Platform/
Middleware
- Persistence
- Transactions
- Distribution
- Scheduling
- Hardware Access
Programming Language
Operating System
- 13 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – Separation of Concerns & AOP
•
Since not all the domains in a system are „components“
and thus directly modularized, separation of concerns
and concerns weaving is required.
•
This requirement can be adressed by several means,
among them
• the architecture of a system (interceptor pattern, e.g.)
• or on language level using Aspect Oriented
Programming (AOP).
• Or using model-driven code generation
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 14 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – How does AOP work I
•
Many concerns in software systems cannot be localized
(or modularized) with traditional techniques (and cannot
be handled easily on architectural level)
The following example shows session handling code in the
apache web server (in red).
•
Not being localized
creates a whealth of
problems:
• It cannot be plugged
in or out easily
• It‘s hard to change
the strategy by
replacing the code
• It is not readily
available for reuse
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 15 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – How does AOP work II
•
AOP aims at localizing the cross-cutting concern in a
separate entity, the aspect.
•
This solves the problems
mentioned on the previous
slide.
•
However, you need
additional stuff to make
that work:
• You need additional programming language constructs
to describe aspects and their „attachments“ to regular
code
• You need a tool that does the weaving for you
(statically, or at runtime).
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 16 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – How does AOP work III
•
•
•
•
Developer develops
program code
Aspect
Aspect
Aspect
Aspect
Aspect
Normal OO
Program
Developer develops
(or reuses) aspect
code
Weaving
Specification
Developers specifies the
weaving rules (defines
pointcuts)
Aspect Weaver
Aspect Weaver weaves
program and aspects
together and produces
the „aspectized“ program
ingenieurbüro für softwaretechnologie
Woven Program
w w. w .voelter .de
- 17 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – Domain Specific Languages
•
While staying on the expressive level of programming
languages, the ability to become more domainspecific is limited.
•
Key to make software development more domain-specific
is to use Domain-Specific (Programming) Languages
(or DSLs) to express domain concepts and functionality.
•
These DSL-Programs are then translated to executable
code using transformation or code-generation tools
(this process is not unlike what compilers do – just based
on your own, domain-specific language).
•
This approach is called Model-Driven Software
Development, or MDSD.
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 18 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – How does MDSD work
several
platform
Metametamodel
subdomains
design
expertise
Application
bounded area of
knowlege/interest
partial
composable
multi-step
multiple
knowledge
transform
viewpoint
Domain
single-step
compile
Model
semantics
Ontology
interpret
no
roundtrip
•
•
•
precise/
executable
Domain
Specific
Language
graphical
A domain metamodel describes
Metamodel
textual
the core concepts of a domain
A DSL adds sematics and a concrete syntax and allows for
building precise and complete models.
The models are transformed into executable applications
that run or a certain platform by a transformation or code
generation tool
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 19 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – Simple DSL Example
•
The following is an example model for a J2ME system,
desribed in a simple, graphical DSL
["Abort"]
["Exit"]
["Again"]
Display
Form
CalcResult
NumberEntry
a: Number ["a"] {a>0}
b: Number ["b"] {b>0}
•
>> a,b
["Result"]
c: Number;
c=a+b
>> c
["The Result is "+c]
{align=center}
1
to
1
from
Element
On the right side, is the
metamodel for the DSL.
UIElement
Calculation
name : String
declaredVars: String
expression : String
Start
End
outbound
*
inbound
*
Flow
Form
Display
label : String
constraints: String
Field
AutoFlow
Button
transportedVars: String
label : String
transportedVars: String
varName : String
label : String
constraints: String
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 20 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – MDSD Benefits I
•
Models are free of implementation artifacts – they directly
represent domain knowledge and are thus reusable.
•
Implementations for various platforms can be generated in
principle – the technology change problem is adressed to
some extend.
•
Technology freaks and domain experts can take care of
„their business“ (transformations and models, respectively)
and need to care of each other‘s problems only in a limited
way.
•
Domain experts can play a direct role in development
since they can more easily understand models expressed with
a DSL as opposed to implementation code.
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 21 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – MDSD Benefits II
•
Development becomes more efficient since repetitive
implementation code can be generated automatically.
•
Architectural contraints/rules/patterns can more easily be
enforced, since the they are embedded in the templates
rather than just being documented (and ignored).
This is especially important in really large teams, often in the
context of Product-Line Engineering and Software System
Families.
•
Transformer/Generator can address cross-cutting concerns
(just like an aspect weaver)
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 22 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – MDSD Predjudices
•
MDSD does not require UML – any kind of modelling
language is ok, graphical or textual
•
Precise and complete models…
• … are not the the same as „visualized code“ – the
abstraction level is higher
• … are not the same as analysis models – analysis models
are not computational
•
MDSD does not require – not even recommend – a
waterfall. Development of the generative infrastructure is
iterative and incremental.
•
You do not need big and expensive tools – a lot of small
and useful open source tools are available.
•
You don‘t need to generate 100% of the code – it is ok,
to also code some aspects in a 3GL.
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 23 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
DDD Techniques – AOP vs. MDSD (not necessarily MDA)
•
•
•
•
•
•
•
•
•
•
•
Both can be used to separate concerns.
Both can be used to factor out (and later, re-integrate) repetitive,
often technical aspects
Technically, both work with queries on models/code and
transformations on the selected model/code elements.
AOP can be applied to finished systems after the fact.
AOP works on the level of the (3GL, OO) programming language
MDSD can introduce domain-specific notations that appeal to
non-developers, too.
MDSD can also produce/integrate non-programming-language
artifacts such as build files
The AO idea can be applied on modelling/DSL level, too.
The MDSD Generator can handle some of the cross-cutting
concerns (in the templates, or by weaving the models representing
the various aspects.
MDSD can use aspects as an implementation technology.
MDSD can generate an „AO Architecture“ (proxy, interceptor…)
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 24 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
Expressive
DDD Techniques – How
it all fits together
Manually
Written Code
Model
Model
Model
Model
Code
Generator
DSL
Metamodel
Codegen Templ.
Model-Driven (Design Patterns)
Software
Devlopment
Cfg
File
Executable
Executable
Artifacts
Executable
Artifacts
Executable
(EJBs)
Artifacts
(EJBs)
Artifact
(EJBs)
(EJB)
Aspect
Aspect
Aspect Weaver Oriented
Programming
Domain X
(Banking)
Cfg
File
Executable
Executable
Artifact
Executable
Artifact
Executable
(EJB)
Artifact
(EJB)
Artifact
(EJB)
(EJB)
Aspect
Aspect
Aspect
Domain Y
(Security)
API
Domain A
(Web Apps)
Architecture/
Platform
Plattform
(App Server)
Expressive
Code
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 25 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
The End.
Thanks
Questions?
Comments?
Criticism?
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 26 -
© 2004 Ma rk u s Vö l te r
DOMAIN–DRIV EN
D E V E L O P M E N T: Introduction
The other talks:
•
Arno (11:00)
Some concepts on using AOP to keep the code and the
domain model in sync
•
Rickard (13:00)
Experiences on using AOP for implementing a commercial
product
•
Markus (14:15)
Experiences (Best Practices) of Model-Driven Software
Development from condensed several projects
•
Steve (15:45)
Microsoft’s Approach to MDSD called Software Factories
•
Panel: Your questions…
ingenieurbüro für softwaretechnologie
w w. w .voelter .de
- 27 -
© 2004 Ma rk u s Vö l te r