Self-documenting infrastructure would be a godsend. I ctrl-f'd for 'self-doc' because I was wondering when we will start seeing Terraform, Puppet, etc., have options to generate a diagram automatically as part of their normal operation. This makes working with the code in your IDE and reading it as much of a pleasure as any other well written code, having it in your SCM also gives you a history of how the code has changed over time.įinally, use of the tool is optional, if you hand the the repository over to another team, or as a contracter you deliver it to a client, they don't need the tool, and just get code which looks as if it was written by a good developer. Our own templates generate code which is as beautiful looking and readable as code written by the best developers, and we encourage template writers to do the same.

If you want to change the signature of the method, for example adding a parameter, then our code generation will add it in without messing up your custom code. This is very useful for cases where you want to model signatures of methods in our tool, but then leave it to the developer to implement the method which performs the business code. The main reason is that our 'code management' (essentially code weaving) system allows coders to painlessly mix their own custom code in the same file as generated code. I would never go back to building business software any other way. When juniors ask questions of seniors, they can both talk around the UML so that they quickly get clarity on the best way forward. We are always able to talk around these visual models when planning a new feature or strategising a technical solution for a requirement.Īn architect can at any time reason about the domain without having to first build up a mental model of it from code. The enormous advantage of this approach is that the documentation (in the form of UML in this case), never goes out of date and lives with the code, it’s literally checked in to our Git repo in an SCM friendly format next to the normal code. Towards this we have used a tool which not only allows us to visually model the domain using UML, but also performs what we call “code management” (smarter code-gen which doesn’t get in your way, or produce ugly code) which turns the UML into code for our ORM of choice.Īll members of the team are required to use the tool and UML to create new domain entities which then automatically become (beautifully formatted) code. It worked of if people defined foreign keys and kept the naming consist.įull disclosure: I am one of the developers of a product which does the below, also known as model driven architecture.įor about 5 years now, the teams I have been on have found great success in the use of DDD. That data was always updated.įor MySQL databases in the past I used a tool that was able to create the table diagram from the schema in MySQL but I had to spend quite some time to rearrange the tables with drag and drop. The changes in the UI became real changes in the system. In a company I was working long time ago, we had a GUI to connect parts of the systems. The exceptions are tools that get their data from the system. I remember seeing some version control tools for diagrams but unfortunately unless the design is updated as the code gets updated, these tools are worthless.Ĭomments that are in the code get outdated. Git blame and diffing commits have become the only good tool able to tell me what I need and also help me to realize what changed overtime, by who and when. In the systems that do not drastically change, it is sometimes useful later to understand how the system was initially designed by new people.īut for specific part of the system I always have to look into the code on source control.

A diagram gets obsolete very quickly.Ī diagram is mostly valuable in the design phase for me and to have faster less ambiguous discussion with people. Systems change, people that work on them change.

Static in staruml