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.
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?
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.
We do this as well at Purple [0]. It does make issue referencing in commit messages a bit unwieldy; you have to include the full path to the issue (e.g., org-name/repo-name#34).
Interesting, haven't heard of it before. Thanks for the link! Afer reading their Github page, the differentiation between Brighty and FOMO is that Brighty consolidates messages into structure information. This helps users read only the important information with little effort.
I do appreciate when tools/libraries take the time to explain the problem and how they differ from their competition. Especially in cases like this, where it's an underlying architecture difference.
The various Rake servers (Puma, Unicorn, etc.) have also done a great job of this.
