|
2 | 2 | [](README.md) |
3 | 3 | [](https://github.com/SaaStacked/saastack/actions/workflows/build.yml) |
4 | 4 |
|
| 5 | +[](https://www.saastacked.com) [](https://www.saastacked.com) [](https://www.saastacked.com) |
| 6 | + |
| 7 | + |
5 | 8 | # SaaStack |
6 | 9 |
|
7 | 10 | Are you about to build a new SaaS product from scratch on .NET? |
@@ -57,16 +60,15 @@ or, if you prefer hosting on AWS: |
57 | 60 |
|
58 | 61 | ## How is the code structured? |
59 | 62 |
|
60 | | -150+ projects!! |
61 | | - |
62 | | -Yes, 150 projects! Why? because the world has moved on. |
| 63 | +100+ projects!! |
63 | 64 |
|
64 | | -If you are used to cramming in all your code into one or three assemblies for your API, then you are not managing dependencies very well at all. |
| 65 | +Yes, 100 projects! Why? because the world has moved on, and you are building a long-lived highly maintainable product now. |
65 | 66 |
|
66 | | -Even if you think you are, your favorite IDE makes it far too easy to violate decoupling rules, just by adding a `using` statement to some type, you are inadvertently adding dangerous coupling. Then, later down the track, when scaling out becomes an issue, how will you factor out that code from that tight set of assemblies into another deployable unit, when the code is all tangled up with all the rest of that code? You can't. That's why we have automated tests, and a bunch Roslyn rules to stop you accidentally creating *accidental complexity* for the sake of expediency. |
| 67 | +If you are used to cramming in all your code into one or three assemblies for your API, then you are not managing dependencies very well at all, and that thing simply isn't going to scale. Too much software in too few deployable units. |
67 | 68 |
|
68 | | -Instead, what you will want at that time is a codebase structure with a very intentional separation of "modules" and separate deployable units. That are designed to be separated. These "modules" are best contained across assemblies that are explicitly separated in layers, and backed by tooling to enforce that separation, and enforce the decoupling of types - to avoid the spaghetti code that is always ahead of your team today and tomorrow. |
| 69 | +You need to structure things better to manage complexity in the long run. Even your favorite IDE makes it far too easy to violate de-coupling rules, just by adding a `using` statement to some type, somewhere else in the codebase you are possibly inadvertently adding dangerous coupling. Then, later down the track, when scaling out becomes an issue, you won't be able to factor out that code from that tight set of assemblies into another deployable unit. You simply can't. That's why we have not only very structured boundaries, but we have also included automated tests, Roslyn analyzers and other developer tooling to prevent and warn you when you are accidentally create *accidental complexity* for the sake of expediency. |
69 | 70 |
|
| 71 | +So not only are you getting a comprehensive production-ready, and battle tested codebase, ready to go, you are also getting a very structured and maintainable codebase that is ready to grow with you, with the tools to keep things clean in the future. Its quite a bit more that a project template. |
70 | 72 |
|
71 | 73 |
|
72 | 74 | The best experience for working with this template is in an IDE like JetBrains Rider, or Visual Studio, or Visual Studio Code (with solution file). |
@@ -187,3 +189,34 @@ The starter template also takes care of these specific kinds of things: |
187 | 189 | * It utilizes common patterns and abstractions around popular libraries (that are the most up-to-date in the .NET world), so you can switch them out for your preferences. |
188 | 190 | * It defines horizontal layers and vertical slices to make changing code in any component easier and more reliable. |
189 | 191 | * It enforces dependency direction rules so that layers and subdomains are not inadvertently coupled together (enforcing architectural constraints) |
| 192 | + |
| 193 | +## Is this all you get? |
| 194 | + |
| 195 | +From this open source project, you get all this for _Free_: |
| 196 | +* You can clone, build, test, run, debug, and develop all this locally! |
| 197 | + * No local dependencies on any infrastructure, no databases, no docker containers, nothing! |
| 198 | + * Develop on Windows, On MacOS, On Linux. |
| 199 | +* The codebase is team ready, so you can onboard new team members and get them up to speed quickly. |
| 200 | +* You can start designing and building your product right now, complete with a CI pipeline in GitHub. |
| 201 | + * Build out your product |
| 202 | + * Demo it to your company from your local machine. |
| 203 | + |
| 204 | +But what you can't yet do, is deploy this into a commercial production environment: |
| 205 | + |
| 206 | +For that you need a few more things: |
| 207 | +* You need a set of cloud provider connectors to connect to: databases, queues, message buses, and APM for monitoring |
| 208 | + * So you can run this product in either Azure or AWS. |
| 209 | +* You need a set of production environment technology adapters, to interact (both ways) to various 3rd party services |
| 210 | + * For example, to connect to: SSO Providers, Twilio, Mailgun, Stripe, UserPilot, LaunchDarkly, etc. |
| 211 | +* You need an automated deployment pipeline to push releases to a cloud production environment, in minutes. |
| 212 | +* And you could use some more helpful documentation to learn the patterns and techniques |
| 213 | + * Coding standards for your team |
| 214 | + * Tools to keep consistency |
| 215 | + * Rules and conventions to train your favorite AI tool to help you knock out your future product at rapid speed! |
| 216 | + |
| 217 | + |
| 218 | +That is what [SaaStack Standard](https://www.saastacked.com) and [SaaStack Premium](https://www.saastacked.com) are all about. |
| 219 | + |
| 220 | +<a href="https://www.saastacked.com"><img alt="SaaStack Licenses" src="docs/images/Skus.png" width="850" /></a> |
| 221 | + |
| 222 | +Upgrade, for a one time fee, and get access to everything to launch your new product in the cloud. Then get access to community of other SaaS builders who are extending the core architecture for more mature SaaS products and services. |
0 commit comments