Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Practical Enterprise Application Development<br />
Agenda<br />Introduction<br />Enterprise Architecture and Design<br />What is Bad Design?<br />Good Design Principles for ...
Introduction<br />Why we are here?<br />From Project development to Product development<br />As we build framework on thes...
Enterprise Architecture<br />   “Enterprise Architecture is typically used to describe an organization-wide framework for ...
Enterprise ArchitectureDeveloper’s point of view<br />Defining a process, framework and set of patterns to design, develop...
Enterprise Development<br />Patterns and practices adopted by programmers endeavoring to implement enterprise architecture...
Hold on hold…<br />One might think that simple, non-enterprise code that delivers a particular feature is identical in val...
Bad design is...<br />Hard to change!<br />A single change break lots of other code<br />Rigid<br />Fragile<br />Can’t be ...
Good Design Principles<br />Enterprise development requires a change in methodologies<br />We are going to look some good ...
The Single Responsibility Principle<br />"A responsibility is a reason to change, a class or module should have one, and o...
The Single Responsibility Principle<br />“There should never be more than one reason for a class to change.”<br />Dijkstra...
BusinessPartnerValidator<br />BusinessPartner<br />Validator<br />DB<br />Trade<br />What is wrong here: Changes if DB cha...
RefactoredBusinessPartnerValidator<br />BusinessPartner<br />Validator<br />BusinessPartner<br />Source<br />Trade<br />DB...
The Open Closed Principle<br />“Software Entities (Classes, Modules, Functions, etc.) should be open for extension, but cl...
The Open Closed Principle<br />Modules that conform to the open-closed principle have two primary attributes<br />Open For...
The Open Closed Principle<br />Abstraction is the key to achieve it<br />Server<br />Client<br />Closed Client<br />
The Open Closed Principle<br />Abstract Server<br />Client<br />Server<br />Open Client<br />
Liskov Substitution Principle<br />“Functions that reference a base class must be able to use objects of derived classes w...
Dependency Inversion Principle<br />“High level modules should not depend upon low level modules. Both should depend upon ...
BusinessParty Validator<br />Introduce stability with abstraction<br />High Level (Less Stable)<br />BusinessParty<br />So...
Better BusinessPartner Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartnerValidator<br />BusinessP...
Extensible BusinessParty Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartyValidator<br />Trade<br ...
Let’s Do It<br />DEMO<br />
Reference and Further Learning<br />Professional Enterprise .NET<br />Jon Arking and Scott Millett<br />Combating Software...
Upcoming SlideShare
Loading in …5
×

Practical Enterprise Application Development

1,536 views

Published on

Good Design Principles for Enterprise App Development

Published in: Technology

Practical Enterprise Application Development

  1. 1. Practical Enterprise Application Development<br />
  2. 2. Agenda<br />Introduction<br />Enterprise Architecture and Design<br />What is Bad Design?<br />Good Design Principles for Enterprise Development<br />Single Responsibility Principle<br />The Open Close Principle <br />Dependency Inversion Principle<br />Demo: Applying Principles<br />
  3. 3. Introduction<br />Why we are here?<br />From Project development to Product development<br />As we build framework on these principles<br />We want you to start taking care of them<br />To achieve our vision we need to strive for it<br />
  4. 4. Enterprise Architecture<br /> “Enterprise Architecture is typically used to describe an organization-wide framework for portraying and incorporating the business processes, information flows, systems, applications, data and infrastructure to effectively and efficiently support the organization needs.”<br />
  5. 5. Enterprise ArchitectureDeveloper’s point of view<br />Defining a process, framework and set of patterns to design, develop, build and maintain all the software that an organization<br />Unified development platform for creating all elements of software at all levels of design<br />The reusable elements can then be used to geed or drive other applications with similar need<br />Defining solid foundation of code and practices that eventually facilitate interoperability in the heterogeneous software environment<br />
  6. 6. Enterprise Development<br />Patterns and practices adopted by programmers endeavoring to implement enterprise architecture<br />They address five key areas:<br />Reliability<br />Flexibility<br />Separations of Concerns<br />Reusability <br />Maintainability <br />
  7. 7. Hold on hold…<br />One might think that simple, non-enterprise code that delivers a particular feature is identical in value to enterprise code that delivers precisely the same feature?<br />While enterprise sample might look a bit more complex (only at first), the resulting class or module ultimately provides more reliability or is more maintainable <br />
  8. 8. Bad design is...<br />Hard to change!<br />A single change break lots of other code<br />Rigid<br />Fragile<br />Can’t be ‘extended’ <br />Immobile<br />
  9. 9. Good Design Principles<br />Enterprise development requires a change in methodologies<br />We are going to look some good design principles now<br />By core, we take care of two things<br />Modularity<br />Loosely Coupled Classes<br />
  10. 10. The Single Responsibility Principle<br />"A responsibility is a reason to change, a class or module should have one, and only one, reason to change."<br />
  11. 11. The Single Responsibility Principle<br />“There should never be more than one reason for a class to change.”<br />Dijkstra’sSoC: Separation of Concerns<br />Applies on every level of code<br />
  12. 12. BusinessPartnerValidator<br />BusinessPartner<br />Validator<br />DB<br />Trade<br />What is wrong here: Changes if DB changes or Business Logic Changes<br />
  13. 13. RefactoredBusinessPartnerValidator<br />BusinessPartner<br />Validator<br />BusinessPartner<br />Source<br />Trade<br />DB<br />What's its job?<br />Classes must have an identifiable single responsibility. <br />
  14. 14. The Open Closed Principle<br />“Software Entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification”<br />
  15. 15. The Open Closed Principle<br />Modules that conform to the open-closed principle have two primary attributes<br />Open For Extension<br />behavior of the module can be extended<br />Closed for Modification<br />The source code of such a module is inviolate<br />The normal way to extend the behavior of a module is to make changes to that module. How can these two opposing attributes be resolved?<br />
  16. 16. The Open Closed Principle<br />Abstraction is the key to achieve it<br />Server<br />Client<br />Closed Client<br />
  17. 17. The Open Closed Principle<br />Abstract Server<br />Client<br />Server<br />Open Client<br />
  18. 18. Liskov Substitution Principle<br />“Functions that reference a base class must be able to use objects of derived classes without knowing it."<br />
  19. 19. Dependency Inversion Principle<br />“High level modules should not depend upon low level modules. Both should depend upon abstractions. “<br />“Abstractions should not depend upon details. Details should depend upon abstractions.”<br />
  20. 20. BusinessParty Validator<br />Introduce stability with abstraction<br />High Level (Less Stable)<br />BusinessParty<br />Source<br />BusinessParty<br />Validator<br />Trade<br />DB<br />Low Level<br />(More Stable)<br />
  21. 21. Better BusinessPartner Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartnerValidator<br />BusinessPartySource<br />Trade<br />DB<br />
  22. 22. Extensible BusinessParty Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartyValidator<br />Trade<br />WSBusinessPartnerSource<br />DbBusinessPartySource<br />DB<br />Cloud<br />
  23. 23. Let’s Do It<br />DEMO<br />
  24. 24. Reference and Further Learning<br />Professional Enterprise .NET<br />Jon Arking and Scott Millett<br />Combating Software Entropies with Design Principles and Patterns at Tech-Ed ME<br />HammadRajjoub<br />ObjectMentor.com <br />http://www.objectmentor.com/resources/articles/<br />Practices and Patterns on MSDN<br />http://msdn.microsoft.com/en-us/practices/default.aspx<br />

×