The document discusses combining Domain Driven Design (DDD) and Model Driven Software Development (MDSD). It proposes directly mapping the DDD domain model to the MDSD model and the DDD ubiquitous language to a Domain Specific Language (DSL) in MDSD. This would more concretely define the ubiquitous language in the DSL. The model would be a manifestation of the domain using the DSL. Challenges in the mapping are discussed, as DDD and MDSD try to be general, and manifestations of models and languages are undefined. The document explores evolving a DSL and domain model in this combined approach.
Almost all software development activities require collaboration, and model-based software development is no exception. In modern model-based development collaboration comes in two levels. We start from collaborative language creation (aka metamodeling) and describe the benefits it can provide and then do the same for collaborative language use (aka modeling). We conclude by inspecting how the collaboration enables scalability in terms of multiple engineers, multiple languages, large models, and transformations.
Fusing Modeling and Programming into Language-Oriented ProgrammingMarkus Voelter
Modeling in general is of course different from programming (think: climate models). However, when we consider the role of models in the context of “model-driven”, i.e., when they are used to automati- cally construct software, it is much less clear that modeling is different from programming. In this paper, I argue that the two are conceptually indistinguishable, even though in practice they traditionally emphasize different aspects of the (conceptually indistinguishable) common approach. The paper discusses and illustrates language-oriented programming, the approach to {modeling| programming} we have successfully used over the last 7 years to build a range of innovative systems in domains such as insurance, healthcare, tax, engineering and consumer electronics. It relies on domain-specific languages, modular language extension, mixed notations, and in particular, the Jetbrains MPS language workbench.
Patterns and Anti-patterns
How to learn design patterns?
Categories of GoF patterns
The Fundamental theorem of software engineering
Real-world problems and how design patterns solve them with GoF structural patterns
Our research lines on Model-Driven Engineering and Software EngineeringJordi Cabot
Highlighting some of our research lines (March 2015 Edition)
Learn more about what we do on : http://modeling-languages.com , http://som-research.uoc.edu and http://jordicabot.com
Almost all software development activities require collaboration, and model-based software development is no exception. In modern model-based development collaboration comes in two levels. We start from collaborative language creation (aka metamodeling) and describe the benefits it can provide and then do the same for collaborative language use (aka modeling). We conclude by inspecting how the collaboration enables scalability in terms of multiple engineers, multiple languages, large models, and transformations.
Fusing Modeling and Programming into Language-Oriented ProgrammingMarkus Voelter
Modeling in general is of course different from programming (think: climate models). However, when we consider the role of models in the context of “model-driven”, i.e., when they are used to automati- cally construct software, it is much less clear that modeling is different from programming. In this paper, I argue that the two are conceptually indistinguishable, even though in practice they traditionally emphasize different aspects of the (conceptually indistinguishable) common approach. The paper discusses and illustrates language-oriented programming, the approach to {modeling| programming} we have successfully used over the last 7 years to build a range of innovative systems in domains such as insurance, healthcare, tax, engineering and consumer electronics. It relies on domain-specific languages, modular language extension, mixed notations, and in particular, the Jetbrains MPS language workbench.
Patterns and Anti-patterns
How to learn design patterns?
Categories of GoF patterns
The Fundamental theorem of software engineering
Real-world problems and how design patterns solve them with GoF structural patterns
Our research lines on Model-Driven Engineering and Software EngineeringJordi Cabot
Highlighting some of our research lines (March 2015 Edition)
Learn more about what we do on : http://modeling-languages.com , http://som-research.uoc.edu and http://jordicabot.com
Explain Domain-Driven Design, its main concepts and tools, and the Event Storming practice to highlight the importance of a good design and empower a team to start using it progressively.
Creating high-quality designs by applying relevant patterns is a key skill of an architect. When you learn patterns by “discovering” them through real-world examples and case studies, you’ll remember them forever. The special feature of this presentation: First a design problem is presented and when you refactor it, you’ll discover that it is actually a design pattern (that’s an unusually effective way to discover patterns)!
Many people who start exploring Domain-Driven Design (DDD) are wondering what it's all about. Some argue that all those implementation pattern are important. Others say that these patterns should have been excluded from the Blue Book in sake of strategic design. I mostly agree with the latter and explain why in this presentation. It was presented at the first DDD Norway meetup in Oslo, on the 1st of March 2017.
Domain-driven design is a collaborative process involving both domain experts and software practitioners that attempts to address issues of complexity in software. This process is described in the book Domain-Driven Design written by Eric Evans. Domain-driven design starts with the assertion that complexity is in the domain, not in the technology. Accordingly, we must let technology play a supporting role.
A person practicing domain-driven design does not attempt to model reality. Instead, domain experts and software practitioners use a mental model as a tool for solving problems within a given domain. The domain experts and software practitioners collaborate to explore and develop this model. We will look at the concept of a bounded context within which models can be isolated and explored. We will talk about domain-driven design's building block patterns including entities, value objects, aggregates, repositories, services, and domain events. We will see how test-driven development can be used as a means of exploring the model.
User Centered Design Patterns and Related Issues – A ReviewWaqas Tariq
A design pattern describes possible good solutions to common problems within certain context. This is done by describing the invariant qualities of all those solutions where good patterns improve with time and widespread use. In this research paper some existing user centered design patterns and their issues are discussed. We have studied many user centered design patterns; however most of them do not provide diagrammatic solutions which can be implementable. It is observed that there is a need of a design pattern which can address issues specifically related to Open Source Software (OSS) users.
In this deck I describe twenty best practices for using external DSLs to develop software (also know as Model-Driven Development). The best practices are based on my personal experience, but they are also rated based on feedback I received from a number of colleagues to express the level of confidence experts have in the particular best practice.
The slides cover three main aspects: language definition, model processing as well as process and organizational issues. Examples include the importance of notations, viewpoints and partitioning, the role of constraints, model transformations and testing as well as some thoughts on documentation, reviews and project roles.
Putting twenty best practices into 5.000 words of course results in each best practice being quite brief. However, it also means each is highly condensed and to the point. I believe the slides remind developers of most of the critical aspects of using DSLs, and it can serve as a checklist when starting an MD* project.
Following on from the success of last year, this annual event for London's architect community will have architectural innovation as a theme this year, and particularly CQRS. At the DDD eXchange we will feature leading thinkers and architects who will share their experience and Eric Evans is the programme lead.
MODIGEN: MODEL-DRIVEN GENERATION OF GRAPHICAL EDITORS IN ECLIPSEijcsit
Domain-specific modeling is more and more understood as a comparable solution compared to classical software development. Textual domain-specific languages (DSLs) already have a massive impactin contrast
tographical DSLs, they still have to show their full potential. The established textual DSLs are normally generated from a domain specific grammar or maybe other specific textual descriptions. And advantage of textual DSLs is thatthey can be development cost-efficient. In this paper, we describe asimilar approach for the creation of graphical DSLs from textual descriptions. We present a set of speciallydeveloped textual
DSLs to fully describe graphical DSLs based on node and edge diagrams. These are, together with an EMF
meta-model, the input for a generator that produces an eclipse-based graphical Editor. The entire project
is available as open source under the name MoDiGen.
Explain Domain-Driven Design, its main concepts and tools, and the Event Storming practice to highlight the importance of a good design and empower a team to start using it progressively.
Creating high-quality designs by applying relevant patterns is a key skill of an architect. When you learn patterns by “discovering” them through real-world examples and case studies, you’ll remember them forever. The special feature of this presentation: First a design problem is presented and when you refactor it, you’ll discover that it is actually a design pattern (that’s an unusually effective way to discover patterns)!
Many people who start exploring Domain-Driven Design (DDD) are wondering what it's all about. Some argue that all those implementation pattern are important. Others say that these patterns should have been excluded from the Blue Book in sake of strategic design. I mostly agree with the latter and explain why in this presentation. It was presented at the first DDD Norway meetup in Oslo, on the 1st of March 2017.
Domain-driven design is a collaborative process involving both domain experts and software practitioners that attempts to address issues of complexity in software. This process is described in the book Domain-Driven Design written by Eric Evans. Domain-driven design starts with the assertion that complexity is in the domain, not in the technology. Accordingly, we must let technology play a supporting role.
A person practicing domain-driven design does not attempt to model reality. Instead, domain experts and software practitioners use a mental model as a tool for solving problems within a given domain. The domain experts and software practitioners collaborate to explore and develop this model. We will look at the concept of a bounded context within which models can be isolated and explored. We will talk about domain-driven design's building block patterns including entities, value objects, aggregates, repositories, services, and domain events. We will see how test-driven development can be used as a means of exploring the model.
User Centered Design Patterns and Related Issues – A ReviewWaqas Tariq
A design pattern describes possible good solutions to common problems within certain context. This is done by describing the invariant qualities of all those solutions where good patterns improve with time and widespread use. In this research paper some existing user centered design patterns and their issues are discussed. We have studied many user centered design patterns; however most of them do not provide diagrammatic solutions which can be implementable. It is observed that there is a need of a design pattern which can address issues specifically related to Open Source Software (OSS) users.
In this deck I describe twenty best practices for using external DSLs to develop software (also know as Model-Driven Development). The best practices are based on my personal experience, but they are also rated based on feedback I received from a number of colleagues to express the level of confidence experts have in the particular best practice.
The slides cover three main aspects: language definition, model processing as well as process and organizational issues. Examples include the importance of notations, viewpoints and partitioning, the role of constraints, model transformations and testing as well as some thoughts on documentation, reviews and project roles.
Putting twenty best practices into 5.000 words of course results in each best practice being quite brief. However, it also means each is highly condensed and to the point. I believe the slides remind developers of most of the critical aspects of using DSLs, and it can serve as a checklist when starting an MD* project.
Following on from the success of last year, this annual event for London's architect community will have architectural innovation as a theme this year, and particularly CQRS. At the DDD eXchange we will feature leading thinkers and architects who will share their experience and Eric Evans is the programme lead.
MODIGEN: MODEL-DRIVEN GENERATION OF GRAPHICAL EDITORS IN ECLIPSEijcsit
Domain-specific modeling is more and more understood as a comparable solution compared to classical software development. Textual domain-specific languages (DSLs) already have a massive impactin contrast
tographical DSLs, they still have to show their full potential. The established textual DSLs are normally generated from a domain specific grammar or maybe other specific textual descriptions. And advantage of textual DSLs is thatthey can be development cost-efficient. In this paper, we describe asimilar approach for the creation of graphical DSLs from textual descriptions. We present a set of speciallydeveloped textual
DSLs to fully describe graphical DSLs based on node and edge diagrams. These are, together with an EMF
meta-model, the input for a generator that produces an eclipse-based graphical Editor. The entire project
is available as open source under the name MoDiGen.
Following on from the success of last year, this annual event for London's architect community will have architectural innovation as a theme this year, and particularly CQRS. At the DDD eXchange we will feature leading thinkers and architects who will share their experience and Eric Evans is the programme lead.
Applying DDD and CQRS can not only make the resulting design of our system simpler and more effective but, freeing us from the burdenof the “one model fits all” approach, also allows architects to adopt different strategies when it comes to business logic modeling. Though lot has been written about DDD and CQRS, missing working code publicly available seems to be the elephant in the room: in this talk, we’ll find out how to implement the “Command side of the Force” by means of a proper Domain Model and getting to the point of switching from an entity based modeling to an event based one.
This workshop focuses on domain driven design and how to achieve it effectively. It also focus on bridging gaps while gathering requirements from business stakeholders using event storming workshops.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
How world-class product teams are winning in the AI era by CEO and Founder, P...
Domain Driven Design and Model Driven Software Development
1. Domain Driven Design and Model Driven Software
Development
Karsten Klein, hybrid labs, January 2007
Version: 1.0
Introduction
Eric Evans Book ‘Domain Driven Design’ was first published end of 2003 [Evans2003]. It
has been very well received by the object oriented software development community and
many of the described concepts have been successfully applied.
During the J2EE era the attention on the domain model has been shifted in favor of
technology significantly. The central objective that Evans advocates is to realign focus onto
the domain model again, rather than on the utilized technologies the system is build upon.
In [Evans2003] the topic of Model Driven Software Development (MDSD) is only touched in
a limited, but perhaps the only adequate fashion taking the point of time into consideration. In
the past years the concepts provided in the Domain Driven Design (DDD) realm have proven
to be very helpful in constructing healthy and sustainable software. In the meantime MDSD
experienced a renaissance. After code-generation approaches were largely abandoned the
Model Driven Architecture (MDA) and MDSD initiatives have brought back the idea of
generating artifacts from models utilizing Domain Specific Languages and are constantly
gaining momentum in industrial environments.
This article is supposed to provide a common ground for elaborating the opportunities of
combining and Model Driven Software Development (MDSD). Please note that OMG’s
Model Driven Architecture® (MDA®) [OMG-MDA] is largely excluded from these
considerations, since the MDA paradigms are again quite technical and focus on the platform
independence, which is explicitly not regarded as a domain concern.
Domain Model and Ubiquitous Language
The domain model is essential. It reflects the understanding of a particular domain using
classes, attributes, relationships and collaboration behavior. It can be extended with additional
information and constraints. The domain model is the central communication tool, with which
is constantly nourished with further insights and requirements. It also becomes the pivot for
communication and influences the language we speak about the domain. Evans [Evans2003]
introduced the term ‘Ubiquitous Language’ in this conjunction. The ubiquitous language
evolves with the domain model and enables to describe the characteristics of the domain with
increased precision. The ubiquitous language is the common ground of the software engineers
and the domain experts. Error prone translations are minimized.
Interestingly DDD and MDSD have a large intersection here. The focal point of DDD is the
domain model and the ubiquitous language supporting it, while MDSD projects start with a
Domain Specific Language (DSL) and a model facilitating the DSL.
Directly mapping domain model (DDD) to model (MDSD) and the ubiquitous language to a
DSL is of course a very abstract and adventurous mapping initially, but it could at least be a
possible interpretation of domain model and DSL from the MDSD point of view.
The main problem here is that both parties - DDD and MDSD aficionados - try to be as
general as possible. The DDD person does not determine how the domain model is expressed.
2. Normally the DDD domain model is determined by several artifacts including drawings,
documentation, annotations and – most favorable and complete - code. In fact Eric Evans in
[SE-8-2006] puts it much more abstract: “A model […] is a set of related concepts that can be
applied to solve some problem […].” and “The model itself is a set of abstractions, a set of
rules of how these abstractions interact […]”. The manifestation of the model is not
determined at all. It can be represented by anything appropriate. In conclusion the same can
hold true for the ubiquitous language. Reading [Evans2003] the ubiquitous language appears
to be the spoken language, which simply but consequently uses the abstractions and terms
defined by the domain model. The manifestation of the ubiquitous language is concluded to
be undefined as well.
On the other hand the MDSD community does not determine how model and DSL should
look like. The manifestation of both therefore is depending on the utilized MDSD
infrastructure and the used concepts. Normally the DSL is represented by an appropriate meta
model. The model – granting the target domain as constant - can be simply seen as function of
the DSL.
model domain A = f (DSL domain A)
So what speaks against directly mapping the DDD domain model to the MDSD model and the
DDD ubiquitous language to a DSL? The ubiquitous language used for communication would
be more concretely defined in the DSL. The DSL is just a (partial) manifestation of the
ubiquitous language. The model is the manifestation of the domain using the DSL.
Of course this mapping will never be a hundred percent. In [SE-8-2006] Eric Evans expresses
that he sees this approach as an attempt towards domain driven design, which is still cluttered
with too many technical artifacts, hiding the important information inherent in the domain
model.
However, pursuing this thinking can open new perspectives. In the subsequent chapters a
possible mapping of DDD to MDSD is provided. Please regard this as an experimental
approach, which tries to raise some questions, encourage discussion and eventually may
reveal some opportunities.
Evolving a DSL specific to Domain Driven Design
Given the idea of a DDD driven MDSD approach the first obvious thing to do is to construct
an appropriate meta model. This will of course not be a one time task, but a continuous effort
in order to reflect the evolving knowledge about the domain and the ubiquitous language.
Approaching this in a pragmatic fashion a DSL is considered, which is specific to the problem
of doing domain driven design, not yet taking the specificity of the problem domain into
account. It is a DSL for the domain ‘domain driven design’ – a DDDSL. The specificity to the
problem domain is completely represented by the model.
Put into other words, the DDDSL defines the vocabulary, the model defines the language. For
example the terms ‘entity’ and ‘value object’ are part of the vocabulary and the
‘RouteSpecification’ is a term of the model. Both are part of the ubiquitous language.
One could also say that the ubiquitous language is an instance of the Domain Driven Design
meta model and therefore located on a lower abstraction level as a DSL (which may be a first
insight).
3. Evolving the Domain Model
Taking the previous section as granted the model can be expressed using the DDDSL. While
developing and extending the model the ubiquitous language will evolve, too. Moreover the
DSL will be extended as required for being able to express the domain model.
Assuming we have a very final idea of a DSL, how is the domain model now expressed in
order to represent a valid MDSD model ready for generating code?
Before continuing it is very important to have sacrificed the ‘holy grail of domain driven
design’ [Evans2003]. MDSD is explicitly not a discipline of generating everything. You will
never try to express object behavior with a MDSD model. You will never try to make your
DSL as expressive as a programming language.
Technical Domain Model
The modeling of the technical domain model can be easily done with a UML tool. UML is
widely known and since the technical domain model should facilitate a medium for
communication with non-software developers it appears to be the best choice.
The UML is extended by a so-called profile containing stereotypes and tags to be used during
the modeling. The profile provides the vocabulary to be used in the technical domain model.
It seems that many people are alarmed when hearing that they have to do the design using
UML. In fact you don’t have to. It is just an opportunity. Currently activities in the MDSD
community go into the same direction. Often UML tools are not very handy, when the DSL is
kind of simple. The MDSD community has made a significant effort into being able to easily
build custom editors for a DSL [OAW2006].
In the scope of this article a modeling with UML is chosen.
Constraints
Constraints significantly supplement a standard UML model. However apart from low-level
constraints it is hard to find standardized mechanisms to express general constraints in your
UML model and have them being expressed correctly in code for checking object instances at
runtime. There are activities to standardize constraints using the Object Constraint Language
(OCL) specified by the OMG [OMG-OCL]. Based on OCL a variety of tools supporting your
MDSD approach can be found [Kent-OCL] [EMF-OCL] [Voelter2006].
Some OCL tools support OCL checks only on the model level that means on an abstract level
higher than one would naturally expect the constraints when talking about the domain model.
When looking at any OCL tooling in the MDSD area, make sure that the level the OCL
expressions are written and when they are applied is clear. E.g. the constraints used in
[Voelter2006] are expressions on the level of the meta model and are used to check
consistency of the model. They have nothing to do with the domain model as such.
Code
The behavior of objects can be best expressed with code. We basically do not put any code in
the model, but we nourish the generated code with additional functionality. The initial result
from a generator run on the constructed model, can therefore only result in a preliminary
anemic object model. The specific behavior has to be added manually by the software
developers. There are techniques to accomplish this task and not mixing any generated and
4. hand-crafted code (see section “Recipes – Integrating generated and non-generated code” in
[Voelter2006]). Such a separation should be ensured to be able to rerun the generator without
eliminating the hand-written lines.
Documentation
Documentation is a continuous effort. You document the model using free-text notes as you
design it, you document the code as your write it. Documentation – in the sense of Eric Evans
always uses the ubiquitous language.
Further documentation describes the APIs including the services that are exposing your
domain model towards a client.
Manifestation of the Domain Model with MDSD
In summary the domain model is an aggregation of everything expressing it. That means it is
the holistic composition of the technical domain model (including the constraints), code and
documentation. Compared to a classic domain driven design approach nothing has changed in
this respect. Only – and this is the added value – the model and the language to describe the
model are made much more explicit! They evolve as part of the whole and are always up to
date.
Summary
“So far I haven’t seen much in the MDA round that has been useful to me in this way.”
Supposing that Eric Evans included the MDSD approach in this statement (which he probably
does taking the context of the interview [SE-8-2006]) it is of central relevance for this article.
Listening to the interview one can get the idea that the interviewer is a MDSD-affectionate
(not to fond about MDA) and the interviewee, Eric Evans, is very keen on not allowing
MDSD/MDA to enter the realm of Domain Driven Design. I personally found the interview a
little disappointing. It is professional and respectful, but does not add anything new. The
MDSD advocate can not manage to push the DDD evangelist into a direction to jump on the
potential opportunities, while the DDD evangelist obviously simply doesn’t want to be
pushed that way. He finds DSLs exciting, but does not differentiate MDA, MDSD and Case
Tools to a large extend and is revolting about the technological complexity. They do not meet
on the topic that would have interested me the most.
In this article I have largely laid out my idea of combining DDD with an MDSD approach.
And this is actually the way I’m currently pursuing my project work. There are still a lot of
unknowns and shortcomings, but I highly appreciate and advocate the fundamental idea of
Domain Driven Design to render the domain model as central element of software
development.
The following sections summarize the findings and opportunities in this respect.
Opportunities
Domain Model and Ubiquitous Language are more Explicit
Since the knowledge about a domain is not only in documentation, but is the fundamental part
of the DSL and therefore the technical domain model it has become more general and explicit.
Designers and developers have to use the language to design the model. It is not personally
flavored and cannot be miss-interpreted, since it directly results in generated code.
5. Domain Models are Normalized
The resulting technical domain models focusing on different domain, but using the same
Domain Driven Design DSL are normalized. Domain specificity is inherent to the model not
the DSL. The DSL can be reused, which also offers standardization opportunities for the DSL
and the underlying generator framework (e.g. standard templates addressing different aspects
of the software architecture).
Focus on the Domain Model
The designers and developers can finally focus on the domain model. They design the
technical domain model, they add hand-written code supplementing the resulting generated
code. All the rest – the layered architecture, the technologies used, etc. is taken care of by the
generator provided. The argument that designers and developers are not defining the language
they require to talk about the domain ([SE-8-2006]) does not hold true. They base the
language on the DSL (which they can influence) and construct their language aligned to the
technical model they design.
Technical Domain Model always Up-to-Date
Since the technical domain model in the MDSD arena is part of the source of a module, it is
always up-to-date by definition. If a change needs to be done on the model it does not first
happen in the code, but it does first happen in the technical domain model. Therefore, the
technical domain model – the key artifact for communication purposes – is never outdated.
All Advantages of MDSD apply
In general all the advantages of MDSD apply. E.g. you do not find the developers doing error
prone repetitive tasks all day long. Once having identified such a need the generator can be
easily extended to address this in a general reusable way as part of the MDSD infrastructure.
Moreover the approach provides a high degree of flexibility concerning the software
architecture. Ultimately the architecture can evolve, while designers and developers have to
make no adaptations.
Conclusion
The article tried to outline that DDD and MDSD can be combined in unison. It provides a
very natural approach to achieve the goals of both worlds and to build on the respective
advantages. By listing the opportunities in the summary section it tries to open the readers’
mind of pursuing the one or the other option in this context.
The article is meant to continuously evolve in the future. Please do not hesitate to provide
feedback to contact@hybridlabs.org.
“Perhaps someone will take some of the things that the MDA people have worked out and
maybe they create a new modeling language […]. I think experiments are great and I hope
that people continue trying all sorts of things.” Eric Evans [SE-8-2006]
References
[Evans2003] "Domain-Driven Design: Tackling Complexity in Software", Addison-
Wesley 2003
[Avram2004] “Domain Driven Design Quickie”, http://infoq.com/books/domain-
drivendesign-quickly
[SE-8-2006] “Interview with Eric Evans”, http://www.se-
radio.net/index.php?post_id=67317
[OMG-OCL] “OCL Specification”, http://www.omg.org/docs/ptc/03-10-14.pdf