4 ms·
OK, so that covers data modeling, and I agree with you that that is a rare and yet critical skill. But if I'm envisioning correctly the talents that you're desc
by Myrmornis 9y ago
OK, so that covers data modeling, and I agree with you that that is a rare and yet critical skill. But if I'm envisioning correctly the talents that you're describing, that still leaves a large amount of concurrent/asynchronous logic undescribed/undesigned. I expect you know what I mean; maybe a jumble of words like "multiple superimposed event-driven parallel state-machines" gives the idea.
You mention a "domain object model". Are you talking about diagrams that capture much of the dynamics/asynchronous behavior that I described (in which case, where can I learn about such a diagramming language?) or is it more restricted to the nouns?
- aryehof 9y agoI am talking about a domain model of the problem under consideration. That model is the same thing from analysis/design to code. It is independent of technical concerns and plumbing. Independent of a particular interface or mechanism for persistence. I'm talking about using standard programming language features, rather than yet another (diagrammatic) language that requires translation to executable code. Those technical concerns are dependent on the non-functional requirements of the particular required solution. This includes aspects of concurrency. I suspect your interested in a "framework" that supports both problem domain modeling and specific technical circumstances?