Oof, big topic. Yes, this can be a typical pattern in enterprise-class software, but I don't necessarily think it's a good one. Consider avoiding it if you can. The core issue here is that it exists at a super-high level of abstraction. When a tool doesn't know what the user wants to do, it inevitably abdicates the decision and gives you a framework for building your own tool. This starts off as a cool sales pitch about customizability, but in some ways MDA is the ultimate scope creep; if you become that flexible, really there's nothing your software can't do (in theory).
This is such a classic mistake that there are all kinds of jokes about it.
Zawinski's Law -- "all truly useful programs experience pressure to evolve into toolkits and application platforms"
Greenspun's Tenth Rule -- and others too.
Bottom line for me, MDA exists at a very high level of abstraction. Systems should avoid over-abstraction. I think it's too much to say categorically that you should never do this, sometimes it might work, but you better have a damn airtight case why it's necessary before you do it, otherwise I'd argue it's over-abstraction.
Specific engineering design patterns - really it's about creating database entities and relationships in a very abstract way, and allowing the user with a UI to specify and relate those things. On the UI side, same concept except instead of using database entities/relationships, you're using panels, inputs, forms, etc.
Open source alternatives - not sure on this one, but I would be wary of them if there are, because usually "super flexible" solutions end up getting customized to the problem domain (CRM, or whatever). Maybe some of the interface and data builders that come with Eclipse?
The issues that come with these approaches are many.
Testing the Beast
Because it's so abstract, testing becomes very hard. It's not possible to test every combination, so designing a representative covering suite is a very hard thing to do. That new feature you developed, does it interact poorly with Customer X's bizarre customization that was really working against how the tool was supposed to function in the first place?
Understanding Your Own System
Second, it allows the user to encode knowledge into the system that the system itself doesn't have. Imagine a back-end engineer looking at a customization of his own system and having a hard time recognizing where to start, because knowing your way around depends on knowledge outside of the system's specs. An earlier commenter pointed out that for salesforce, you have to hire special consultants to help you implement it. Yep, sounds right.
Inappropriate User Expectations
There's a general tradeoff between system power and simplicity; these systems are very powerful, and tend to be the opposite of simple. So basically all of the downsides of complexity come in the bargain for more flexibility. This also creates in the users and product managers a sense of "we can do anything" which makes it very difficult to set and understand proper system scope boundaries.
As others have said, the Façade pattern is an obvious way to go. To add to the answers thought, I'd like to say, you need to think carefully about the semantics of the API you are trying to wrap when creating the simpler Façade. Syntax is the easy part.
For example, your API may require an initialisation function followed by functions which actually do the bit you are interesting in, followed by a tear down before allowing a new init. If you abstract away the init part are you potentially adding unnecessary processing with every API call (init, process, tear-down) without the user knowing that they are doing so.
Obviously, my example is completely hypothetical, but it just goes to illustrate that you need to think carefully about how the API is simplified so unintended consequences are not introduced.
Best Answer
This is a "Module" pattern, as well as a "People" pattern - your code may look different as well but that's not where the meat of the difference lies. I think you understand what the pattern is given the situation you're trying to apply it to.
Actually applying it would look like the following:
Assume the Core Platform's the lowest layer in your "stack".
In code, these three layers would be in different packages - which you probably already have. Make certain that no layer below makes any specific reference to or has a dependence on something in the layers above. That will protect your Platform from complexities of your Products and Customer specific stuff. Create some series of Facades and other simple abstractions between any layer and the ones below it. For example, my Facade to a database Module in the Core Platform may consist of a Factory that will generate an instance that adheres to a "DataSource" interface, as opposed to someone on your Core Product team directly reaching into the Core Platform (not through the Facade) and concretely instantiating a SQLDatabaseSource instead. This will protect your Product and Customer layers from changes in the implementation of your Platform.
Secondly, the teams must be structured to communicate effectively in a manner conceptually matching this "downstream" approach. The Platform team must show interest in what features the Product teams need the most, cleanly document how to use them, and cleanly design them so that the Customer team doesn't have to tightly couple their implementation to it. They also have to make it clear the ways in which they are unwilling or unable to accomodate the teams downstream. Perhaps they will have the slowest cycles, as opposed to your Customer team, whose lower number of stakeholders (1 customer company as opposed to the 100 your platform team may ultimately serve) allows for faster iterations.
In light of all this, I think you may want to re-think the name "Core Products", because it's just confusing that you're building "Core" products on top of "Core" platform. Core means inside, so only one can be that.
Cant believe they took this off stackoverflow