Designing a dimensional DB off a normalized source that already implements SCD's
As you are seeing, one of the benefits of Kimball Dimensional Modeling is that the data warehouse design is essentially your SSAS design. While there are always exceptions, you can typically select a table in the DSV and immediately move to hierarchy design, cube relationships etc.

I'd recommend moving to the DDS with the caveat that you phase out the NDS. For the simple reason that you mention with the SCD Type II - there's no reason to duplicate all of that data, ETL, and code base. Keeping both leads to an overly complex solution with a lot of maintenance and risk - this is the primary Big Mess™ you need to avoid.

Here's the justification:


The DDS sounds like a Kimball dimensional design that will be easily
understood and maintained by any new hires and contractors
There are lots of proven designs for schema and ETL that go along with this, making it easier to design and maintain
Easier to deal with large data quantities via options like fact partitioning and column store indexes
Easier DW queries in the future for yourself and power users
Simpler overall design


The alternative design I'd suggest only if you have small quantities of data, no significant expectation of increases, and no capacity to switch to the data warehouse. This suggestion ultimately includes a lot of the design work that would otherwise go into the DW and as such is similar to keeping the NDS and creating the DDS:

You can create your cubes with queries manifested as Views or hard-coded into the DSV.

It sounds like you overcame a lot of hurdles and created a great functional solution with the NDS. Unfortunately what it doesn't do are two important things that dimensional modeling provides: simple query patterns and easy translation into multidimensional analytics. Thankfully, a lot of the ETL design is likely useful as a template or starting point for loading a different table structure.