In my previous post I explained that, as a developer, you do not create applications but in fact systems, living entities that react to their envir...
For further actions, you may consider blocking this person and/or reporting abuse
While I'm okay with the general approach of system design, I'm opposed to anything getting to the detailed level of UML.
I believe it's a broken notion that there is a useful description of systems that can both be read at a high-level and directly converted to technical implementations.
You're also doing over-design and this ends up slowing down project process, and paralyses participants by preventing them from deviating from an agreed upon design. Technology driven systems need to be highly flexible during develpoment or face an increasing risk of failure.
UML and its relatives have a point if you're throwing specifications over the wall to another team you can't interact with directly (or vice versa). Then you really do need to have things laid out with that kind of detail.
If you're throwing stuff over a wall then your system is doomed to failure. I know this kind of spec and hand-off approach was popular at one point, but it's basically a failed development strategy.
You need a two-way communication with the teams involved in the development of a product.
UML is attempting to patch a fundamentally flawed approach.
Sure, it's flawed if not outright The Wrong Way To Do Things, but that doesn't mean it's not still happening for reasons which are often outside developers' control. And if you want to have any chance of getting something usable out of that kind of process, you need to set stuff in stone.
When you let people design something on their own, they usually draw only boxes with lines. My point is that, when refining your design, you need to use the same convention to describe things, a simple convention that everybody understand and UML can be the right choice for some teams.
A better approach would be to have a human readable format that helps you to make your design (this format could generate UML diagrams) and create also your system at runtime (this format could generate your classes and components). This is the approach I chose for my project (I will develop that in another post).
Before you start: make the "business knowledge" person agree to engage in the process. It's going to take days off time to find the aggregate roots.
Also, don't use UML. UML is great if you've got a very complex relational data model and you want to get your OO designed up front; otherwise it's not much use. You're not "being enterprise" by doing UML like this, you need UML up front and part of the system creation.
I tried this method before but I had trouble getting the customer to explain their problems in this way. None of them wanted to engage like this. Instead we got them to write down user stories that described their business processes and then built the aggregate roots, entities and messages from that.
Wow, this is awesome. Need to test it