Absolutely. Model-driven development and related paradigms like domain-driven design are still in use in almost any area of business software development. Domain-driven design in particular has become quite popular again in recent times and I don't see it going anywhere anytime soon.
The thing is: You have to do it right to reap the rewards. Especially in larger companies it's unfortunately not uncommon to encounter all-encompassing models with hundreds (or even thousands) of entities / classes. That kind of model not only doesn't help with developing software faster and more cost-efficiently but even has an adverse effect. In order to benefit from model-driven development you have to think in terms of the various business functions (sales, HR etc.), the boundaries between those functions and models which are specific to their respective subdomain.
Nah, rapid application development for the most part is a pipe dream. It works for contrived school examples and default CRUD interfaces but as soon as you need custom logic or user interface behaviour it breaks down pretty rapidly.
However, rapid application development isn't the main benefit of these approaches. Their main point is getting a better understanding of the business domain you're operating in.
DDD is basically more of a code first MDD. It's still very much in vogue.
I do like DDD, the idea that you have a project that is completely focused on solving the business issues. Then the infrastructure/technology concerns simply plugin into that model.
Gives you flexibility on changing technologies more easily, and well designed domain model can give you a serious business advantage.
Just curious if you're inside or outside of the US? I hadn't heard this technique mentioned in my undergrad CS at the time I graduated in 2012.
Going off the MSDN article (https://msdn.microsoft.com/en-us/library/aa964145.aspx), MDD, it starts to sound vaguely like how most early-stage startups build software wrt agile. There are definitely tools to generate basic CRUD models from a data model diagram eg UML. There are also tools to generate class diagrams from code. However, they lost me somewhere in the middle of that article where everything quickly detached from reality into abstractions. Beyond those points and using TDD, personally I had a hard time seeing what this approach is exactly and what the value added is.
The Wikipedia article for model-driven software development (https://en.m.wikipedia.org/wiki/Model-driven_software_develo...) makes it sounds like you generate code then never modify it directly, only regenerating from the abstraction. That sounds cool in theory but completely unrealistic in practice.
There is a fair amount of model based design in defence and aerospace, where the systems in question can be years away from being ready and finding bugs when the systems are ready is hugely expensive. This starts to get into Systems Engineering territory (the INCOSE kind not the MCSE kind).
When one gets into Systems of Systems territory, just looking at code isn't an option, and understanding the interactions between systems at a system level can be worth the up front cost of creating the models.
Having models drive code generation (say Simulink generating FPGA code) can also allow for simulation and testing to be done on the model and then the exact same tests be done on target with very little rework.
Probably not any extra time than are required by your studies.
A lot of it can be learned on the job and the organisations I worked with (only in Europe, truth be told) had heavy training sessions for on-boarding. I know because I designed, developed and taught those courses.
Usually those places have a a 'full-stack' of model based systems engineers using SysML, who hand off models to the dev guys using model based development (MBD). Testing with a V-model, etc.
Defence more than automotive, but some orgs have very long project cycles (i.e. >25 years) so models provide a great benefit over simple source/docs.
The thing is: You have to do it right to reap the rewards. Especially in larger companies it's unfortunately not uncommon to encounter all-encompassing models with hundreds (or even thousands) of entities / classes. That kind of model not only doesn't help with developing software faster and more cost-efficiently but even has an adverse effect. In order to benefit from model-driven development you have to think in terms of the various business functions (sales, HR etc.), the boundaries between those functions and models which are specific to their respective subdomain.