5 ms·
Full disclosure: I am one of the developers of a product which does the below, also known as model driven architecture. For about 5 years now, the teams I have
by jonathanlydall 8y ago
Full disclosure: I am one of the developers of a product which does the below, also known as model driven architecture.
For about 5 years now, the teams I have been on have found great success in the use of DDD. 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.
All members of the team are required to use the tool and UML to create new domain entities which then automatically become (beautifully formatted) 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.
We are always able to talk around these visual models when planning a new feature or strategising a technical solution for a requirement.
An architect can at any time reason about the domain without having to first build up a mental model of it from code.
When juniors ask questions of seniors, they can both talk around the UML so that they quickly get clarity on the best way forward.
I would never go back to building business software any other way.
- tachang 8y agoWhat product is it?
- jonathanlydall 8y agoIntent Architect[1]. Our main development focus right now is on usability for new comers and we're improving it regularly. [1] http://intentarchitect.com/ http://intentarchitect.com/
- taeric 8y agoIf the code is generated from the diagrams, why check the code in at all? Feels akin to checking in the bytecode with your the java that generated it.
- rocqua 8y agoI can envision two reasons. The first is that, in truth, the code generated from the UML, isn't good enough and people still actually work on the output. The second guess is that humans occasionally rewrite the code for optimization. It might then be easier to source controll the code rather than patches.
- derangedHorse 8y agoThere's also the reason of not wanting to generate all the code every single time someone new retrieves the repo or needs to revert back to a previous commit.
- taeric 8y agoThis reason doesn't make sense. Again, do you checkin the bytecode of your java? I'd expect you, instead, to recompile the java every time you do a build. Now, I would expect you to have an artifact repository. To that end, you would be able to easily get the generated sources. But, they would decidedly not be in the source repository.
- jonathanlydall 8y agoI don't feel the bytecode comparison makes sense, because the generated code is human readable, bytecode is (to almost all intents and purposes) not. We feel that code generation is something one does explicitly while modelling, not something done every time you build.
- jonathanlydall 8y agoCompletely our thinking too. Code generation should not be a build or run time dependency. Our tool also allows developers to review proposed code changes before choosing to commit them to disk. Code generation is something you choose to do explicitly as you model.
- taeric 8y agoNeither of those seem like compelling reasons, though. If the code isn't good enough, you are better incentivizing the team to improve the tool's generated code, than you are increasing the drift between what the tool generates and what is used. Optimization can almost make sense, but maintaining a patch process is almost certainly the superior way to go. If only because it supports staying current on the generated code.
- maccio92 8y agoWhat is the tool?
- jonathanlydall 8y agoIntent Architect[1]. Our main development focus right now is on usability for new comers and we're improving it regularly. [1] http://intentarchitect.com/ http://intentarchitect.com/
- t3hprofit 8y agore: full disclosure, I appreciate your reply and that it didn't end with "So, you should use program X (the one you work on) because it's the best software". Your objective response is great.
- jonathanlydall 8y agoThank you, regardless of my interests in promoting the idea of using such a tool, we made it because we have found time and time again that always upto date visual documentation such as UML is invaluable, especially as projects get older and bigger. Otherwise, in general we're far more interested in constructive criticism (or even just normal criticism) of our philosophy (and tool) from a place like HN, rather than trying to score a little free "advertising". When the time is right, we'll do proper promotion, and it won't be by spamming forums.