Giter Site home page Giter Site logo

contextmapper / context-mapper-dsl Goto Github PK

View Code? Open in Web Editor NEW
210.0 15.0 27.0 2.54 MB

ContextMapper DSL: A Domain-specific Language for Context Mapping & Service Decomposition

Home Page: https://contextmapper.org/

License: Apache License 2.0

Xtend 23.60% Java 74.30% FreeMarker 2.11%
domain-driven-design domain-specific-language context-mapping service-decomposition ddd dsl contextmapper

context-mapper-dsl's Introduction

Context Mapper

Context Mapper DSL (CML)

Build (master) codecov License Maven Central

ContextMapper is an open source tool providing a Domain-specific Language based on Domain-Driven Design (DDD) patterns for context mapping and service decomposition.

With the ContextMapper DSL language you can express DDD context maps. Once you have modeled your system with the language you can use the provided generators to create UML diagrams, service contracts, and calculate proposals for service decomposition with Service Cutter.

Checkout our website https://contextmapper.org/ to get started. The Context Mapper project has originally been developed as part of research projects at OST (former HSR). You can find the project reports and further background information here.

Features

System Requirements

To use the ContextMapper DSL (CML) you need the following tools:

Getting Started

If you want to use our Context Mapper tool, install the plugin in Eclipse or the extension in VS Code:

  1. Installation of Context Mapper:
  2. Find a detailed manual how to create your first CML project here.
  3. Examples which introduce the language (CML) capabilities can be found here: https://github.com/ContextMapper/context-mapper-examples
  4. Further instructions, user guides and documentation can be found on our website https://contextmapper.org/.

Getting Started (Standalone Library Usage)

If you want to use the Context Mapper DSL (CML) language and the generator tools as standalone library within your Java application you can add the following dependency to your project.

Gradle:

implementation 'org.contextmapper:context-mapper-dsl:6.9.0'

Maven:

<dependency>
  <groupId>org.contextmapper</groupId>
  <artifactId>context-mapper-dsl</artifactId>
  <version>6.9.0</version>
</dependency>

In our context-mapper-standalone-example repository you find an example project showing how to include the library within your project. It further contains code examples illustrating how to use the CML models and the generator tools (PlantUML, MDSL, etc.).

Development

If you want to contribute and setup the IDE for this project on your local system follow the following instructions. Here you get the instructions in more details.

Building the Project

The project currently has two builds since we have to use Maven for building the Eclipse plugin but prefer Gradle in the standalone case. With Gradle you can only build the DSL and the IDE (LSP) project. It is further used to deploy these standalone JARs to the Maven central.

Complete Build with Eclipse Plugin (Maven)

The project uses the Maven Wrapper.

After cloning the project it can be built with the following command within the root directory of the project:

./mvnw clean install

Note: This is an Xtext project and the tests which are evaluating the correctness of the language grammar need an additional maven goal besides test to be executed. Use this command if you want to execute the tests:

./mvnw clean integration-test

Of course they are also executed with a clean install.

Standalone Build Only (Gradle)

To build the standalone projects only, you can use the Gradle Wrapper:

./gradlew clean build

Note: If you want to deploy the libraries into your local Maven repository, you need a GPG key to sign the artifacts:

./gradlew clean publishToMavenLocal -Psigning.keyId=<your-gpg-key-id> -Psigning.password=<gpg-passphrase> -Psigning.secretKeyRingFile=<path-to-gpg-keyring-file>

Setup Eclipse IDE

Since this is an Xtext project you need an Eclipse IDE to work on it. Download the Eclipse IDE for Java and DSL Developers from here. The latest version of Eclipse we worked with is 2019-12.

Importing the project

You can import the project with as an existing maven project (Import -> Existing Maven Project).

Build in Eclipse

After importing the project you will have lots of build errors. This is because you have to generate some Xtext sources first. There exists an eclipse launch configuration called 'GenerateContextMappingDSLInfrastructure' delivered with the project. Run this launch configuration (yes, even if there exist build errors). As soon this has completed, execute a clean build with Project -> Clean... -> Clean all projects.

That's it. You should have a clean workspace now without build errors.

Contributing

Contribution is always welcome! Here are some ways how you can contribute:

Licence

ContextMapper is released under the Apache License, Version 2.0.

context-mapper-dsl's People

Contributors

boxleytw avatar contextmapper-ci avatar mleveist avatar socadk avatar stefan-ka avatar stevenvandijk avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

context-mapper-dsl's Issues

Scoping and multiple CML files

Currently we recommend to use only one CML file to model a system. The reason is that even though it is possible to reference objects in other files, they are not resolved by the generators, which leads to strange behavior.

We have to solve this issue by implementing a proper import-mechanism where the user can decide which other files shall be in scope. Object in files which are not imported must not be referenced (Xtext auto-completion etc. has to be adjusted).

Improve Service Cut generator UI (usability/convenience)

The integration of Service Cutter to produce new Context Maps (service cuts) currently uses the following dialog to configure the solver configuration (criteria priorities):

image

In order to in increase the usability/convenience we could provide actions to change the priority for a complete criteria group (less clicks to change priority for multiple criteria).

MDSL generator: recursively resolve inherited attributes

The data types produced by the MDSL generator currently doesn't resolve attributes which are inherited in CML (extends mechanism).

With this issue we should fix this so that all attributes, including inherited ones, are generated into the MDSL data type definitions.

Temporary scoping solution for #86

With #86 we shall solve the scoping problem and implement a proper import mechanism so that it is possible to distribute a model over multiple files.

Currently this does not work but references to other files are still possible (not resolved by generators). With this issue we want to reduce the scope to the file level, so that only objects within the same file can be referenced. Thereby we ensure consistency with the current solution.

#86 shall solve the problem better later.

New keyword "refines" on Bounded Context to specify which other Bounded Context is refined by this context.

Similar to the "implements" keyword and subdomains, add a new keyword "refines" which allows the user to specify that one Bounded Context refines another one. For example: A BC of type SYSTEM could refine a FEATURE/APPLICATION (kind of inheritance feature). Only used to provide modeling information! (will not be used or respected in generators; content of referenced BC is not used anywhere)

PlantUML generator: fix label for Conformist pattern

This issue concerns the PlantUML component diagram generator. At the interface usage there is a label which states the used aggregates and the downstream DDD pattern. The following two cases are possible right now:

  • use aggregates [aggregates] via ANTICORRUPTION_LAYER
  • use aggregates [aggregates] via CONFORMIST

However, the word "via" does not make sense in the Conformist case. The generator shall be changed so that the two cases are generated as follows:

  • use aggregates [aggregates] via ANTICORRUPTION_LAYER
  • use aggregates [aggregates] as CONFORMIST

Team should be able to realize multiple bounded contexts

With the realize keyword it is currently already possible to define which bounded context is realized by a team. See example team map.

However, it is only possible to reference one bounded context. Since a team can also work on multiple bounded contexts, the grammar should allow to specify a list there.

New AR: "Suspend Partnership"

Implement a new AR which is able to remove/suspend a partnership by offering to
a) merge the bounded contexts
b) extract a new bounded context with common parts and establish upstream-downstream relationships,
or c) move commonalities to one of the two bounded contexts and create an upstream-downstream relationship between the two.

Dependency conflict in Eclipse 2019-12

There are dependency conflicts when I try to install the Context Mapper plugin in Eclipse 2019-12. Eclipse suggests to not install the Service Cutter part.

TODO:
The target definition and plugin dependencies have to be fixed so that the plugin can be installed in all of the latest Eclipse versions.

MDSL generator: generate "serves as" and "with responsibility"

The MDSL generator shall generate the "serves as" attribute on endpoints and the "with responsibility" attribute on operations, according to the MDSL grammar.
Solution: the generator shall parse the "doc"-String from Sculptor in CML for the MDSL patterns. If a pattern can be matched, the corresponding attribute value shall be set. Otherwise it should just set the "doc"-String as String value.

MDSL generator: support enums

MDSL as well as CML support enums, but they are currently not created by the MDSL generator.

--> Add enum support to the MDSL generator.

Service Cutter input mapping: map operations to nanoentities

CML to Service Cutter input model mapping:

Currently we create nanoentities for CML attributes. According to the Service Cutter paper, operations can be mapped to nanoentities as well. With this issue we should enhance the model converter to create nanoentities for CML operations as well.

New AR: "Extract Shared Kernel"

Implement new AR which removes the referenced Shared Kernel, creates a new Bounded Context for the Shared Kernel, and adds two new Upstream-Downstream relationships with the new Bounded Context as upstream and the two existing Bounded Contexts as downstream.

Upstream-Downstream vs. Customer-Supplier grammar keyword ambiguity

Context: According to our interpretation of the DDD patterns and our semantic model, a Customer/Supplier relationship is a special form of an Upstream/Downstream relationship. Every Customer/Supplier relationship is also an Upstream/Downstream relationship. But not every Upstream/Downstream relationship is a Customer/Supplier relationship.

Problem: The current grammar/syntax does not explicitly express the definition above, which may lead to confusion, if the user is not very familiar with our semantic model and our understanding of the DDD patterns.

We currently have two keywords for specifying Upstream/Downstream relationships:

  • Upstream-Downstream
  • Customer-Supplier

With the current implementation of the DSL, a relationship which is declared with the Upstream-Downstream keyword actually means "Upstream/Downstream but not Customer/Supplier". Further, a relationship which is declared with the Customer-Supplier keyword is actually both, Customer/Supplier and Upstream/Downstream, but this is not made explicitly clear by the language.

Potential Solution 1: We have to find another keyword to replace Upstream-Downstream, which expresses that this is only one specific form of Upstream/Downstream, such as Generic-Upstream-Downstream (according to the model). This may indicate that this is not the only form of Upstream/Downstream. However, a better and shorter keyword would be nice. But still we somehow want to work with terms which are familiar to the DDD community if possible.

Potential Solution 2: Somehow redefine the declaration of a Customer/Supplier relationship to explicitly express that this a Customer/Supplier AND a Upstream/Downstream relationship.

Input and ideas are welcome!
If you have any idea how to improve this, maybe another solution, or a good keyword for one of the solutions above, please share it with us. Your contribution is very welcome!

XMI / JSON export

  • Check if the XMI export works correctly and contains all model information (users mentioned missing parts)
  • Maybe we should also provide an export to a JSON format (idea)

Grammar improvement: Order of the elements in the relationship rule

Grammar: the order of the elements inside a relationship should not be fixed.

Example:
{
implementationTechnology="JSON over RESTful HTTP"
upstream implements OPEN_HOST_SERVICE, PUBLISHED_LANGUAGE
downstream implements ANTICORRUPTION_LAYER, CONFORMIST
}

At the moment the implementationTechnology must come before the upstream and downstream roles. Would be nice if the order does not matter here and it is possible to define the implementationTechnology at the end.

MDSL generator: use Domain Vision Statements

Generate the Domain Vision Statements (DVSs) of the upstream and downstream Bounded Contexts to the MDSL file too.

  • Generate the upstream DVS as comment on the provider (or contract on the top.)
  • Generate the downstream DVS as comment on the client.

MDSL generator: usage context

Generate attribute usage context on service specification as follows:

  • visibility:
    • if OHS is implemented -> COMMUNITY_API
    • if OHS and PL is implemented -> PUBLIC_API
  • direction: BACKEND_INTEGRATION (we cannot distinguish between frontend and backend for now)

Do not generate empty PlantUML diagrams

Bug
If a CML model does not contain appropriate data to generate a UML diagram, the generator currently just creates an empty diagram.

Expected behavior
Either show a message in Eclipse or at least add a note element in the PlantUML diagram which explains why the diagram is empty.

Idea for generator: „Pure Sculptor“ output

Our Sculptor part has been adjusted and is no longer compatible with the original Sculptor generator tool.

Idea: a generator could produce Sculptor compatible code so that users still can use the original tool.

Distributed Context Mapping in multiple teams

User feedback: How can we work with CML if we have multiple teams and all work on their own Context Map? Is there a way to integrate the different Context Maps somehow (bring them together; one big picture)?

This is just an idea so far, not yet clear how we solve this.

Formatting and DSL root element order issue

Limitation description
Because of this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=369175 and the currently implemented workaround https://www.eclipse.org/forums/index.php/t/1080047/, the application of an Architectural Refactoring (AR) currently de-serializes the complete CML model and brings all root elements into the default order. User-specific formatting is not preserved completely.

To Reproduce:
Steps to reproduce the behavior:

  1. Create CML model with the root elements in non-default order (for example bounded context before the context map).
  2. Add some user-specific (non-conforming to formatter implementation) in a part of the model which will not be changed by your AR.
  3. Apply the AR.
  4. The order of you root elements will be changed and your user-specific formatting is corrected according to formatter implementation.

Expected behavior:
Ideally, an AR should only de-serialize the model elements which are changed by the AR. Regarding the order of the elements it would also be nice to have a more user-friendly solution (don't know the solution by now).

Help is welcome:
If someone knows how to solve this better with Xtext, we are happy to hear.

Let Bounded Context implement complete Domain

With the "implements" keyword we currently allow to specify which subdomains are implemented by a bounded context. Also allow to "implement" the complete domain (one reference to Domain object instead of multiple references to Subdomains).

Command line mechanism to generate plantuml files

Hi,

I have been going through docs and trying your examples to explore the possibility of using "Domain Driven Design" in our team. The examples are good and they work easily with Eclipse IDE.

It would be helpful if there is a command line way to generate plantuml files other than running Eclipse plug-in.

Please let me know if there is a command line way to generate plantuml files.

Regards
KMK
K.Manikandan

Graphviz has not been found on your system

Describe the bug
Whenever I try to generate graphical context map, I get the message "Graphviz has not been found on your system". Although graphviz is installed on my Debian Linux host - this what I obtain when I run apt-file list graphviz:

graphviz: /usr/bin/acyclic
graphviz: /usr/bin/bcomps
graphviz: /usr/bin/ccomps
graphviz: /usr/bin/circo
graphviz: /usr/bin/cluster
graphviz: /usr/bin/diffimg
graphviz: /usr/bin/dijkstra
graphviz: /usr/bin/dot
graphviz: /usr/bin/dot2gxl
graphviz: /usr/bin/dot_builtins
graphviz: /usr/bin/dotty
graphviz: /usr/bin/edgepaint
graphviz: /usr/bin/fdp
graphviz: /usr/bin/gc
graphviz: /usr/bin/gml2gv
graphviz: /usr/bin/graphml2gv
graphviz: /usr/bin/gv2gml
graphviz: /usr/bin/gv2gxl
graphviz: /usr/bin/gvcolor
graphviz: /usr/bin/gvgen
graphviz: /usr/bin/gvmap
graphviz: /usr/bin/gvmap.sh
graphviz: /usr/bin/gvpack
graphviz: /usr/bin/gvpr
graphviz: /usr/bin/gxl2dot
graphviz: /usr/bin/gxl2gv
graphviz: /usr/bin/lefty
graphviz: /usr/bin/lneato
graphviz: /usr/bin/mm2gv
graphviz: /usr/bin/neato
graphviz: /usr/bin/nop
graphviz: /usr/bin/osage
graphviz: /usr/bin/patchwork
graphviz: /usr/bin/prune
graphviz: /usr/bin/sccmap
graphviz: /usr/bin/sfdp
graphviz: /usr/bin/tred
graphviz: /usr/bin/twopi
graphviz: /usr/bin/unflatten
graphviz: /usr/bin/vimdot
graphviz: /usr/share/doc/graphviz/README.Debian
graphviz: /usr/share/doc/graphviz/TODO.Debian
graphviz: /usr/share/doc/graphviz/changelog.Debian.gz
graphviz: /usr/share/doc/graphviz/changelog.gz
graphviz: /usr/share/doc/graphviz/copyright
graphviz: /usr/share/graphviz/lefty/box.lefty
graphviz: /usr/share/graphviz/lefty/def.lefty
graphviz: /usr/share/graphviz/lefty/dotty.lefty
graphviz: /usr/share/graphviz/lefty/dotty_draw.lefty
graphviz: /usr/share/graphviz/lefty/dotty_edit.lefty
graphviz: /usr/share/graphviz/lefty/dotty_layout.lefty
graphviz: /usr/share/graphviz/lefty/dotty_ui.lefty
graphviz: /usr/share/graphviz/lefty/fractal.lefty
graphviz: /usr/share/graphviz/lefty/fractal2.lefty
graphviz: /usr/share/graphviz/lefty/lefty.psp
graphviz: /usr/share/graphviz/lefty/slides.lefty
graphviz: /usr/share/graphviz/lefty/tree.lefty
graphviz: /usr/share/man/man1/acyclic.1.gz
graphviz: /usr/share/man/man1/bcomps.1.gz
graphviz: /usr/share/man/man1/ccomps.1.gz
graphviz: /usr/share/man/man1/circo.1.gz
graphviz: /usr/share/man/man1/cluster.1.gz
graphviz: /usr/share/man/man1/diffimg.1.gz
graphviz: /usr/share/man/man1/dijkstra.1.gz
graphviz: /usr/share/man/man1/dot.1.gz
graphviz: /usr/share/man/man1/dotty.1.gz
graphviz: /usr/share/man/man1/edgepaint.1.gz
graphviz: /usr/share/man/man1/fdp.1.gz
graphviz: /usr/share/man/man1/gc.1.gz
graphviz: /usr/share/man/man1/gml2gv.1.gz
graphviz: /usr/share/man/man1/graphml2gv.1.gz
graphviz: /usr/share/man/man1/gv2gml.1.gz
graphviz: /usr/share/man/man1/gv2gxl.1.gz
graphviz: /usr/share/man/man1/gvcolor.1.gz
graphviz: /usr/share/man/man1/gvgen.1.gz
graphviz: /usr/share/man/man1/gvmap.1.gz
graphviz: /usr/share/man/man1/gvmap.sh.1.gz
graphviz: /usr/share/man/man1/gvpack.1.gz
graphviz: /usr/share/man/man1/gvpr.1.gz
graphviz: /usr/share/man/man1/gxl2gv.1.gz
graphviz: /usr/share/man/man1/lefty.1.gz
graphviz: /usr/share/man/man1/lneato.1.gz
graphviz: /usr/share/man/man1/mingle.1.gz
graphviz: /usr/share/man/man1/mm2gv.1.gz
graphviz: /usr/share/man/man1/neato.1.gz
graphviz: /usr/share/man/man1/nop.1.gz
graphviz: /usr/share/man/man1/osage.1.gz
graphviz: /usr/share/man/man1/patchwork.1.gz
graphviz: /usr/share/man/man1/prune.1.gz
graphviz: /usr/share/man/man1/sccmap.1.gz
graphviz: /usr/share/man/man1/sfdp.1.gz
graphviz: /usr/share/man/man1/smyrna.1.gz
graphviz: /usr/share/man/man1/tred.1.gz
graphviz: /usr/share/man/man1/twopi.1.gz
graphviz: /usr/share/man/man1/unflatten.1.gz
graphviz: /usr/share/man/man1/vimdot.1.gz
graphviz: /usr/share/man/man7/graphviz.7.gz
graphviz: /usr/share/menu/graphviz

To Reproduce
Steps to reproduce the behavior:

  1. Go to CML file
  2. Click on it
  3. Scroll down to 'Generate Graphical Context Map'
  4. See message "Graphviz has not be found on your system"

Expected behavior
Graphical context map gets generated.

IDE and Plugin (please complete the following information):

  • Eclipse version: 2019-12 (4.14.0)
  • ContextMapper plugin version: latest

MDSL generator: operation responsibility

MDSL grammar rule on operation:

('with' 'responsibility' responsibilities=operationResponsibility)?
enum operationResponsibility: COMPUTATION_FUNCTION | RETRIEVAL_OPERATION | EVENT_PROCESSOR | BUSINESS_ACTIVITY_PROCESSOR;

Issue:
Provide the possibility to specify same information on CML methods and generate the attribute above to the MDSL contract.

MDSL generator: protected regions

Provide protected regions for the root elements in a generated MDSL file. If the user moves an element into the region, it will not be overwritten if the generator is called again. Allows to make user-specific changes which are not overwritten.

Context Map type disappears when applying AR

Describe the bug
After the application of an AR, the attribute type is no longer specified on the context map.

To Reproduce
Steps to reproduce the behavior:

  1. Specify type on context map
  2. Apply any AR
  3. Type is no longer specified

Expected behavior
The type should be unparsed as all other attributes.

MDSL generator: add DDD relationship patters as comments on API provider and client

The API provider and client correspond to our upstream and downstream bounded contexts. The relationship between the contexts may comprehend the patterns OHS, PL, ACL, and CF.

To add this information to the MDSL file, generate a comment on the provider with the used upstream patterns (OHS, PL) and another comment on the client with the used downstream patterns (ACL, CF).

MDSL generator: improve generated comments

A few improvements regarding the comments in the MDSL files:

  • the domain vision statement comments shall come one line after the corresponding declarations and not one line before
  • only use single line and not multiple line comments (comments are very prominent at the moment)
  • the domain vision statement of the upstream bounded context shall be generated at the provider, not at the top (API)
  • the upstream and downstream patterns (OHS, ACL, etc.) shall not be abbreviated (generate complete pattern name)
  • the comments mentioning the domain vision statement and DDD patterns, shall mention that this is coming from DDD specification
  • add timestamp comment at top of file
  • try to make the protected region comments less striking

AR idea: "Make roles explicit"

This issue describes an idea for a new AR (maybe more details needed later).

An AR „Make Roles Explicit“, could change a relationship such as A -> B into A [OHS] -> [CF] B. And A <-> B into A [SK] <-> [SK] B correspondingly.

Variants:

  • just generate defaults (as above)
  • implement a UI which allows the user to choose the roles to be added

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.