Hey Everyone! In case you missed it, @MVPKine and I are offering the highly-rated #msdyn365bc workshop we debuted at @BCTechDays 2022 last year as an online class.
I have had folks say "Yeah yeah, but what IS Multi-Application Architecture?"
So here's a 🧵:
For many people writing BC Extensions, particularly folks that are coming from the older NAV C/AL development world, it's very easy to fire up a new Extension, and then you stuff 100% of everything into that Extension. You publish to the client or AppSource, and done, right?
You avoid having ID conflicts, you avoid dependency circles (or even learning about them), and you can find everything in one big monster Mᴏɴᴏʟɪᴛʜ application. Solves everything, right?
It's true, you avoid some problems. But, what happens when you have:
- a BC update with a breaking change
- multiple projects (approvers?) all at once making changes
- deployment problems
- change an integration
- 3rd party solutions added/removed
You then will find yourself slowly walking down the path of "maybe this one part should be its own extension". Quickly, you'll end up with a nice big plate of Dependency Spaghetti.
As we talked about in our @BCTechDays session, which you can watch here, there are better ways:
By using good design decisions, you can map how applications are allowed to own the parts they need, and how to create good rules around the ways a fleet of smaller extensions are allowed to interact.
By doing this, you make your solutions more resilient, more testable, easier to maintain and grow, and reduce your cost (or customer's cost) of owning that solution going forward.
In our session linked above, we cover the S.O.L.I.D. strategy:
Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
But, honestly, *my* favorite two parts of working with @MVPKine on the workshop didn't fit into the 90-minute talk:
The introduction of the SaLi framework for creating logical layers to your applications
Working, hands-on examples of how to step-by-step break a monolith up.
In the session, we looked at the example case of a company growing, adding new functionality over time, adding new integrations, and changing integrations (and dependencies) -the AmuseYou corp.
That was taken directly from the Workshop, where we reviewed, wrote, and rewrote versions of the AmuseYou solutions over the course of the day. The workshop includes exercises to develop the baseline knowledge needed, as well as how to grow.
In the course of the class, we not only talk through all the rules and how to apply them (and how to explain them to customers & stakeholders), but we talk about practical ways to move your *existing* solution forward. How to migrate and evolve.
Hopefully that whets your appetite for attending a little more than a Cerebral Sounding/Theory title.
You can register as an attendee here:
forms.office.com/Pages/ResponsePage.aspx?id=tcPV_VeQJUmo5g8XfKujJiC9pSIa6rNOktCATZRNDRBURjRFOEFOTlg3VEZTSEhDTk1JSk0wVzZUVy4u
How will the class work? You'll get a Teams invite for each session, which is broken out into four 1-2 hour sessions, spread out over 4 dates, and you'll get a recording of each class after.
Aside: If you're wanting to attend, and need a fact sheet to talk to someone about approving the class fee, reach out!
twitter.com/messages/compose?recipient_id=290085463