Limits & Restrictions on Models

Please keep in mind that while there are no hard limits on the size of the models or the number of elements contained therein, at some point in time the models will probably be used to generate some kind of artifacts in an automated manner by the appropriate tools.

To name a few examples, these generated artifacts may include generated source files in a well known programming language (like Java, JavaScript or Python), various visual representations of the model (SVG diagram of the model), nicely formatted documentation for the model (for example in an HTML format) or OpenAPI specification for accessing the data represented by the model programmatically.

Some of this tooling may be limited in its own ways or impose its own restrictions on the size of the artifacts it can handle. Moreover, each of the target domains may impose different recommendations and best practices applicable to it.

You will probably also want to include the generated artifacts in your CD/CI pipeline, where additional restrictions may apply. For example while in Java there is no restriction on the depth of an inheritance hierarchy, static code analysis tools in the build pipeline may impose one depending on the current ruleset in use.

The general recommendations for sizing and using aspect models are:

  • Start integrating all the required tooling as early in the lifecycle of your project as possible. This will for example help you to find out early rather than late if the corresponding payloads are too complex for aspect providers or consumers to efficiently handle.

  • If in doubt, cut your aspect models small rather than large to ensure usability, reusability and efficient handling (multiple Aspect APIs can be provide as multiple endpoints within the same infrastructure)