With modelling UML services, the code (aka model) is the documentation! But like code, models can be unreadable, so some discipline is essential. The new E2E Modeling Guidelines have been published to help developers to better organize, develop, and document their E2E Builder projects.
The E2E Modeling Guidelines cover a variety of aspects:
- Project Organization
When starting a new project, you should give some thoughts to the project organization to make it change-friendly and clear. - Naming Conventions
It makes sense to apply the same naming conventions and containment tree organization to all your Builder projects, as this makes reading a model much easier. As an example, we have published the E2E naming conventions and containment tree organization that have been proven and tested in many projects by our solution delivery team. - Model Documentation
Not all UML diagram types are required to compile and run an xUML service. But understanding often benefits from one or two “unnecessary” diagrams which are solely modeled for documentation purposes. - Settings
To make service settings easy-to-find and reusable, don’t use the inline settings definition (unless it is unavoidable). Use settings classes instead. - Mappings
Find a list of all possible ways to map data and a comparison including pros and cons. - Logging
We explain the main differences between bridgeserver log and transaction log, and give some useful logging hints. - Error Handling
Use executable BPMN to easily implement persistent states with automatic retry capabilities, in case of unexpected errors.
Customize operation’s notifications (Email, JIRA, Nagios) in case of xUML service errors, using our monitoring service with accompanying UI.
We’re hoping you’ll find some inspiration for your daily work in these pages.
Your E2E team
