The heart of the software is a UML Design Model, with a primary focus on the domain and domain logic. It introduces business objects - dervied from textual business concept description - as well as other design work products centered around the model. The model itself is interconnected with the code by serving as a base to generate a subset of the configuration- and software artifacts which gets deployed into the cloud infrastructure.
We use a Domain Driven Design (DDD) approach to shape out the business foundation of the platform. DDD is is an approach to the design of software, based on the two premises:
Refer to the following article for a good introduction
In other words the heart of the DDD is Model and you start developing your application with drawing your model. Model and design you create should shape each other. Model should represent knowledge to the business and it is language your team peak. To be able effectively design you should build your Model and implementation together in the same time, cultivating a language based on the Model. You should represent knowledge in your Model and continuously distill it. You could do refactoring to it doing brainstorming and experimenting.
Integral part of the domain model are the following building blocks:
The Domain Model is a UML based model which is an analysis as well as a design model and is a direct connection to the underlying code.
The UML model is the heart of the software it provides a common language and will not only be used as an aid in early analysis. It’s the foundation of the design and ultimately serve as an input to code generators.
This connection between modeling - not just only for analysis work - but also for used for the design (call it model driven design) is a key requirement in a domain driven design.
Having said that this implies that there is a tight connection between model and the code. As Eric Evans has described in his book, which Martin Fowler describes as the canonical source to DDD.
If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect. At the same time, complex mappings between models and design functions are difficult to understand and, in practice, impossible to maintain as the design changes. A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other.
To establish a model which unifies the analysis as well as the design part(Model-driven design) requires a strong toolset, which is fortunately available as Eclipse Open Source Projects.
We are using the Eclipse Modelling Set, which includes the Papyrus UML Modeller complemented by Acceleo Code Generator and includes EMF, UML, OCL features which are required to describe the model in its necessary details. Refer to the Foundation Chapter for more details about the toolset.
The model itself is expressed by a set of diagrams, which are means of communication and explanation. It’s important to understand that they show design constraints and show conceptually important parts of the object model. But they are not design specifications in every detail.
A lot of the constraints which are driving the code generators are expressed via UML stereotypes attached to UML elements, which are defined in a dedicated UML profile.
As for example in the following diagram attribute name of the business object Customer has some stereotypes attached (representd by <<…>> markers).
Going to the detail view will show the textual definition and configuration of the dedicated items.
As an example
The Business Object Diagram shows objects of importance to a business and documents the relationships between them in terms of responsibilities and behavior. Its emphasizes the roles performed in the business area and their active responsibilities.
In general the generator differentiates the following attribute types
Data Type attributes with the Stereotype
referenceData will be based on name/value list which are fetched by a client from static JSON Files. In the DDD language they are called Value Object
As an example the following
is the source of data, modelled in the following data type:
referenceData has a property
refCode which will provide the information how to fetch the data for the specific ReferenceData DataType,
language parameter is set by end user session (Localization).
Such a data type will be visualized based on a Select2 Remote Select Box, the whole code fragment can be generated.
( /images/Voila_Capture361.png [ReferenceData DataType] %}
Enumeration will be mapped to choices and will be visualized as select values.
In case we are referencing via a class attribute exactly one other Class Object (which has an identity and a lifecycle, called in DDD an Identity Object) we can generate a simple attribute in the code artefacts.
These class attributes are reflecting an endpoint of a navigable association. It’s navigable due to the fact that member end of the association is owned by the classifier (aka the class).
serviceConfig is owned by the classifier
ProductType and therefore represented as class attribute in the UML class. A product type may include one to many serviceConfig(s) and therefore will be handled specially in the generator.
The Business Objects will be stored in a NoSQL datastore, which is suited for data that is modeled documents other that the tabluar relations used in relational databases.
As you can see in the above model diagrams, a class has either the stereotype
The following holds true:
documentCollection will be persisted as JSON document to the underlying data store.
documentProperty will be persisted as part of the
documentCollection which is associated in a navigable way with this one ), actually the association is of type aggregation.
As an example the
ProductType-ProductTypeServiceConfig model construct will result in the following JSON data structure
Again all the necessary meta information required in the code will be generated, by default each of the Class will have by default a unique identifier
As an example the below screenshot shows you the generated AppEngine Objectify Entity (Backend Java Class). It’s class structuring represents the above JSON structure. Such a Entity class object can be transformed from-/to JSON by simply using the Google GSON library.