Domain-Driven Development An introduction Markus Völter

D O M A I N – D R I V E N D E V E L O P M E N T: Introduction

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2 0 0 4 M a rk u s V ö l t e r. - 1 -

Domain-DrivenDomain-DrivenDevelopmentDevelopment

An introductionAn introduction

Markus Völter



Markus Vö[email protected]

www.voelter.de

• Independent Consultant

• Based out of Heidenheim, Germany

• Focus on• Software Architecture• Middleware• Model-Driven Software

Development

About me



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.

Software TechnologyConcepts

Domain Concepts

Software TechnologyConcepts

Domain Concepts

mental workof developers



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.



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.



Hierarchical Structuring of Domains

• Since Domains can be of any size or granularity, it is useful to structure domains hierarchically.

• Automotive Example:

• eBanking Example:

EmbeddedSystems

AutomotiveSystems

Engine Controllers

Diesel Gasoline4-Cyl

eBusinessApps

web-based

RichClients

e-Banking

moneytransfer

inv.bank.



„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



Domains in a Software System

• As a consequence of the classifications on the previous slides, a software system typically consists of several domains:

eBusiness

Web Shop

Payment

Catalogue

Cross Selling

Pers

iste

nce

GU

I

Mul

ti-U

ser/

Con

curr

ency

Sess

ion

Han

dlin

g

System

Com

mun

icat

ion



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



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



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.



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.



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.

DomainPlatform

TechnicalPlatform/Middleware

Operating System

Programming Language

- Persistence- Transactions- Distribution- Scheduling- Hardware Access

- Core Entities- Core Valuetypes- Business Rules- Business Services

Applications



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



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 ofproblems:• 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



DDD Techniques – How does AOP work II

• AOP aims at localizing the cross-cutting concern in a separate entity, the aspect.

• This solves the problemsmentioned on the previousslide.

• 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).



DDD Techniques – How does AOP work III

• Developer developsprogram code

• Developer develops (or reuses) aspect code

• Developers specifies theweaving rules (defines pointcuts)

• Aspect Weaver weavesprogram and aspectstogether and producesthe „aspectized“ program

AspectAspect

AspectAspectNormal OO

Program Aspect

WeavingSpecification

Aspect Weaver

Woven Program



DDD Techniques – Domain Specific Languages

• While staying on the expressive level of programming languages, the ability to become more domain-specific 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.



DDD Techniques – How does MDSD work

• A domain metamodel describesthe 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

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology

bounded area ofknowlege/interest

semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodelplatform

transform

compile

interpret

multi-step

single-step

noroundtrip

knowledge

several

designexpertise

Application



DDD Techniques – Simple DSL Example

• The following is an example model for a J2ME system, desribed in a simple, graphical DSL

• On the right side, is themetamodel for the DSL.

NumberEntryForm

a: Number ["a"] {a>0}b: Number ["b"] {b>0}

CalcResultDisplay

["The Result is "+c]{align=center}

["Abort"]

["Result"]

>> a,b c: Number;c = a + b

>> c

["Again"] ["Exit"]

name : String

UIElement

Form

label : Stringconstraints: String

Display

varName : Stringlabel : Stringconstraints: String

Field

Flow

transportedVars: String

AutoFlow

label : StringtransportedVars: String

Button

Element

Start End

declaredVars: Stringexpression : String

Calculation

1 to

1 from

outbound*

inbound*



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.



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)



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.



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…)



DDD Techniques – How it all fits together

ExecutableArtifact(EJB)



Aspect

AspectAspect

ExecutableArtifacts(EJBs)



ModelModel

Model

Domain X(Banking)

Domain A(Web Apps) Plattform

(App Server)

MetamodelDSL

Model

API

Generator


Domain Y(Security)

AspectAspect Weaver


CfgFile

CfgFile

Codegen Templ.(Design Patterns)

ManuallyWritten Code

Model-Driven Software

Devlopment

Expressive Code

Aspect Oriented

Programming

Architecture/Platform

Expressive Code



The End.

ThanksQuestions?Comments?Criticism?



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…

Domain-Driven Development An introduction Markus Völter

Documents

Transcript of Domain-Driven Development An introduction Markus Völter