contextmapper / context-mapper-dsl Goto Github PK
View Code? Open in Web Editor NEWContextMapper DSL: A Domain-specific Language for Context Mapping & Service Decomposition
Home Page: https://contextmapper.org/
License: Apache License 2.0
ContextMapper DSL: A Domain-specific Language for Context Mapping & Service Decomposition
Home Page: https://contextmapper.org/
License: Apache License 2.0
The integration of Service Cutter to produce new Context Maps (service cuts) currently uses the following dialog to configure the solver configuration (criteria priorities):
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).
The definition of the owners/teams (mainly used for https://contextmapper.org/docs/ar-split-bounded-context-by-owners/) is currently only possible on the Aggregate level. Maybe we should think about providing this information on a higher level (BC)?
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.
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.
MDSL as well as CML support enums, but they are currently not created by the MDSL generator.
--> Add enum support to the MDSL generator.
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.
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:
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:
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).
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:
Expected behavior
Graphical context map gets generated.
IDE and Plugin (please complete the following information):
Entities without any attributes currently lead to an MDSL data type which cannot be compiled by the MDSL compiler. Example:
data type GenericPattern { }
Solution: produce an unspecified type instead:
data type GenericPattern P
Check if there is a possibility in plantUML to add the relationship name to the component diagram.
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:
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).
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:
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.
The resulting attribute type in new service cuts is now "Nanoentity". Choose a new, neutral name instead of the Service Cutter term.
Generate the Domain Vision Statements (DVSs) of the upstream and downstream Bounded Contexts to the MDSL file too.
CML allows to model entities within subdomains, but currently we only generate class diagrams for bounded contexts. Request: generate class diagrams for subdomains.
Generate attribute usage context on service specification as follows:
Provide a refactoring which allows to toggle a relationship between Shared Kernel (SK) and Partnership (P).
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
Upstream-downstream relationships produce a label "use" from the downstream towards the upstream interface. Instead of just "use" we could specify which aggregates are used. Enhance PlantUML generator accordingly.
Bounded Context and Context Map attributes are currently set with a "=".
Example:
type = FEATURE
If possible, make "=" optional so that the following compiles as well:
type FEATURE
CML supports inheritance between entities but it is not correctly mapped to the PlantUML class diagram.
-> generate inheritance correctly
Bounded Contexts can be of different types (reflecting different perspectives: FEATURE, APPLICATION, SYSTEM, TEAM).
Show a compiler warning if there is a Context Map relationship between two contexts of different types.
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.
Hint: Maybe simply use comments.
Attributes in entities, value objects, etc. can be defined 'nullable'.
This should be respected in the PlantUML and MDSL generators:
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.
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.
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.
Hi,
Do you have any plans to create an IntelliJ plugin?
Currently we can model Shared Kernel relationships, but there is no way to actually specify which part of the models is shared.
With this issue we should enhance the language somehow to support this...
The ARs "Extract Shared Kernel" and "Suspend Partnership" create a new empty Bounded Context now (depending on selected mode). Instead of just generating an empty Bounded Context, the ARs should add an Aggregate and an Entity with a comment stating that for example the "Shared Kernel" model can be created there...
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: 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:
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!
... it would be great to support all base types in Sculptor: http://sculptorgenerator.org/documentation/advanced-tutorial#attributes-and-references (most of them work already)
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.
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.
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.
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.
A few improvements regarding the comments in the MDSL files:
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.
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:
Expected behavior
The type should be unparsed as all other attributes.
Splitting ARs may have to be enhanced so that a relationship is created between the two resulting bounded contexts.
Within a bounded context the auto-completion proposes "Doc", but adding it does not compile. Documentation is not supported there. Check why this proposed by auto-completion and if there is anything we can do about it.
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)
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).
They do make to the generated UML. Would be nice to also have them appear as labels in the GraphViz output.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.