Domain-Driven Development An introduction Markus Völter

1. Domain-Driven Development An introduction Markus Völter

2. About me Markus Völter voelter@acm.org www.voelter.de • Independent Consultant • Based out of Heidenheim, Germany • Focus on • Software Architecture • Middleware • Model-Driven SoftwareDevelopment

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. Reasons for DDD • Software Development is too complex andtoo 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 hardlycaptured 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. 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. 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. „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. Domains in a Software System • As a consequence of the classifications on the previous slides, a software system typically consists of several domains:

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. 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. 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. 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. DDD Techniques – Expressive Code • As advertised by the Agile folks, code should be readable like prosetext (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. 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. 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 pluggedin or out easily • It‘s hard to change the strategy by replacing the code • It is not readily available for reuse

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

17. DDD Techniques – How does AOP work III • Developer developsprogramcode • Developer develops (or reuses) aspectcode • Developers specifies theweavingrules (defines pointcuts) • Aspect Weaver weavesprogram and aspectstogether and producesthe „aspectized“ program

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

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

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

26. The End. • Thanks • Questions? • Comments? • Criticism?

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…