1. 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-DrivenDevelopment An introduction Markus Völter

2. 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. - 2 - Markus Völter voelter@acm.org www.voelter.de Independent Consultant Based out of Heidenheim, Germany Focus on Software Architecture Middleware Model-Driven Software Development About me

3. 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. - 3 - 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.

4. 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. - 4 - 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.

5. 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. - 5 - 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.

6. 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. - 6 - Hierarchical Structuring of Domains Since Domains can be of any size or granularity, it is useful to structure domains hierarchically. Automotive Example: eBanking Example:

7. 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. - 7 - „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

8. 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. - 8 - Domains in a Software System As a consequence of the classifications on the previous slides, a software system typically consists of several domains:

9. 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. - 9 - 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

10. 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. - 10 - 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

11. 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. - 11 - 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.

12. 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. - 12 - 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.

13. 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. - 13 - 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.

14. 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. - 14 - 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

15. 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. - 15 - 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

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

17. 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. - 17 - DDD Techniques – How does AOP work III Developer develops program code Developer develops (or reuses) aspect code Developers specifies the weaving rules (defines pointcuts) Aspect Weaver weaves program and aspects together and produces the „aspectized“ program

18. 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. - 18 - 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.

19. 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. - 19 - DDD Techniques – How does MDSD work A domain metamodel describes 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 Model Domain Specific Language Metamodel textual graphical Domain Ontology bounded area of knowlege/interest semantics precise/ executable multiple partial viewpoint subdomains composable Metametamodel platform transform compile interpret multi-step single-step no roundtrip knowledge several design expertise Application

20. 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. - 20 - 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 the metamodel for the DSL.

21. 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. - 21 - 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.

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

23. 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. - 23 - 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.

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

25. 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. - 25 - DDD Techniques – How it all fits together Model-Driven Software Devlopment Expressive Code Aspect Oriented Programming Architecture/ Platform Expressive Code

26. 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. - 26 - The End.  Thanks  Questions?  Comments?  Criticism?

27. 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. - 27 - 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…