I am developing an engineering application (WPF, C#) that consists of a collection of other programs that perform specific engineering tasks. I guess you can think of it like Microsoft Office, however unlike MS Office, the programs within the application all share the same context in that the tasks that they perform all relate to a single job. So just to clarify, imagine I have a job that is the design of an office building. My application would have a collection of programs that perform different engineering calculations relating to the design of the building. Imagine I have a program that designs the footings, a program that designs the beams/columns, a program that calculates loads etc etc. All these programs I call 'design modules', and my main application simply acts as a landing page for all the design modules. It also stores job specific state such job number, address etc.
So to my question. I originally decided to structure my program this way (i.e. a bunch of stand alone programs/design modules that the user can launch from the main application) because I was thinking along the lines that each design module would be a stand-alone application that does not rely on the existence of the other design modules. As I am developing the application, I am realizing that I want to give the user the option to integrate state/data/calculation output generated by each of the design modules more and more with each other. For example, say I generate some loads in the loading module that I want to use throughout the other modules. I need the other modules to be aware of when state changes in the loading module, and to update accordingly. I know i can use some form of IPC to notify other modules when the state changes in another, but I am starting to question the wisdom of my original approach of breaking up the other design modules into separate stand-alone programs. It seems much easier to just create one application and break up the different modules into assemblies, than to break up the modules into separate programs that communicate through IPC.
On the one hand, each design module can truly function independently without relying on state from the other modules, so there really is no absolute need for them to be all be integrated into the one program. The amount of data that can be imported/retrieved from other module outputs is really up to the user. They can use a lot or not at all. On the other hand the best use of the application as a whole would be to have all the design modules work together. They are after all, all trying to design different aspects of the same building, so there naturally is some sort of shared information and intrinsic reliance on the outputs of other design calculations (e.g. if a footing is supporting a column, you need to know the load in the column to design the footing. The user could either manually enter this loading data in, or the footing module could retrieve this data from the column module, if the user chooses).
So my question is what do you guys think the best option is? Keep going with the current approach of having each design module as a separate program, and if required, use IPC to communicate with each other, or just make one single executable without IPC?