[bob1029]

Pretty much. We have an issue in our backlog right now that will pull the platform concern into a completely different project/DLL from the rest of the biz code. We still have a little bit of coupling, but we are 99% of the way there. Our long-term goal is to produce a company-common platform layer that can be used to build a wide range of final products. Most business applications that we would build share a lot of common concerns - namely how to manage business state, client views and transactions with external business systems. This is all implemented in various services within our platform layer so we rarely think about it. When we integrate with a 3rd party vendor's API, it goes into platform so anything can now use that integration.

The crazy thing I've come to realize is that the journey doesn't have to end there either... You can build yet-higher-order abstractions on top of your platform layer (i.e. a platform for platform). I don't know where this all ends up, but 1 or 2 iterations of it has been extremely healthy for our architecture and business use cases so far. We are now able to chain together extremely complex business processes in ways that can be reasoned with in a single POCO mapper. Without a separation of the "noise" of platform-related and other lower-order code from the business code, it would become impossible to see these opportunities.

[thomk]

Bob can you give more details about this or is there a way to contact you? I am genuinely curious about this type of architecture and would love to learn more. If you would rather respond here could you give two simple, concrete examples of each case?

[bob1029]

Based on the responses here, it is apparent that I should spend some time documenting this concept in more detail for the greater good. I do not have the bandwidth for this right now, but perhaps in a few weeks I'll have time to put together some realistic examples for a proper Show HN submission.