In this episode (brought to you by KingswaySoft), Stephan Smith discusses architecture patterns for building Dynamics 365 business systems. As we endeavor to build enterprise scale systems, we must not only consider how it will perform, but how easy will it be to integrate with, upgrade or even migrate to the cloud. System architecture design is the gift that keeps ohn giving to customers and future project teams as it is the underlying basis for which all system functionality depends. By understanding enterprise design patterns, you will be better prepared to convey how systems should be designed and why.

Topics Discussed

• Architecture is a style and there are many styles
  • There are usually many ways to solve a problem
  • Each architect may have an affinity for certain approaches
• One architecture style that is most common is the monolith
  • Easiest and fastest methodology
  • Easier to comprehend for new developers
  • Requires less strategic effort
• Negative symptoms of monolithic architectures
  • Systems don't scale well
  • Systems break more easily when the code is changed
  • Systems are harder to maintain
  • Systems are harder to enhance with comingled features
  • Systems are harder to upgrade
  • Systems require significant refactoring for cloud readiness
• Monolithic architectures typically derive from the following
  • Custom .NET development style mindsets
  • Lack of platform knowledge (features and capabilities)
  • Creating functionality that Dynamics shouldn't be performing
  • Most developers think in an all-inclusive application mindset as opposed to a system mindset
  • Focus on speed of development as opposed to quality and scalability
• The Four Functional Encapsulation Areas
  • Core (Directly services the user's business activity)
  • Ancillary Functionality (Supporting functionality)
  • Integrations (Required interoperability with other systems)
  • Reporting (Operational and analytical reporting concerns)
• Micro-service architecture style
  • Separation of concerns follows a Single Responsibility Principle design perspective
  • Micro-services is a way to break system functionality down into smaller composite parts
    • The codebase has a less complex implementation
    • The code is easier to maintain
• Messaging is a great strategy for near real-time processing between online and on-premises assets
  • Compatible with both on-premises and cloud deployments
  • By refactoring an on-premises system to use messaging we can refactor the code with minimal effort to use Azure Service Bus when migrating to Dynamics online

Social Media

• Stephan Smith (LinkedIn)
• Stephan Smith (Twitter)

Tags Architecture, Design Patterns, Messaging