Table of Contents

[hemmerling] System Design

Organizations & Events

Organizations

Events

Best Practices for "Maintainable Code" & "Good Software Development Structure & Tools

  • SOLID.
  • Clean Code.
  • Design Pattern.
  • Encapsulation.
  • Code Review.
  • DRY ( Don´t Repeat Yourself ).
  • MVC / MVVM.
  • Law of Demeter.
  • TDD.
  • Refactoring.
  • 4 Rules of Simple Design.
  • KISS.
  • Diagnostic Exception Handling.
  • BUS-Factor ( how many team members must leave to kill the project...).

Agile Development - Procedure Models / Process Models

Arc42

Command Query Responsibility Segregation ( CQRS ) & Event Sourcing ( ES )

CQRS and the CAP Theorem / CAP Triangle

    1. Consistency ( all nodes see the same data at the same time )
    2. Availability ( a guarantee that every request receives a response about whether it was successful or failed )
    3. Partition tolerance
  • Classical IT design, including relational ( SQL ) databases, covers “Consistency” and “Availability”.
  • CQRS, as often implemented in NoSQL databases, covers “Availability” and “Partition tolerance”.
  • Messages: Commands vs. events:
    • Commands are imperative, sometimes they are not for every party, there might be exceptions.
    • Events are past, they happened. Events which happened can´t be changed.

Cross-Cutting Concern - The "Opposite"

Resources

Experts

Tools

Convention based Framework vs. Configuration based Framework

Database Application Design by Data Flow Diagrams ( DFD ) & Entity Relationship Diagrams ( ER )

Tools for Database Application Design by Data Flow Diagrams ( DFD )

Resources

Design by Contract / Contract-Driven Development

Codius

D

Resources

Design Patterns

Microservices

Best Practices 2016

  • With web applications built by Microservices, each Microservice is running in its own process ( i.e. with a Java engine, consuming 256 MB RAM ) and not just as Java task within a single Java engine.
    • At start of a Java engine, you may set the RAM memory allocation.
  • So a 64-bit computer with 4 Gbyte of RAM is suitable to run about 10-12 Microservices.
  • Every Microservice of a web applicatoin may be deployed on a different physical or virtual machine.
  • The developers are forced to respect interfaces.
  • Each Microservice may be developed by a different team.
  • For very-large web applications, it might be useful if several Microservices are responsible for a single Web page ( controlled by a major Webservice ). For normal-size web applications, it's best if a single Web page is controlled by a single Microservice.

Best Practices 2017-02, according to ThoughtWorks

Multitenancy

  • Experts told me, that:
    • Multitenancy is a design decision and so a design pattern, which can´t be easily implemented in a software after non-multitenancy implementation afterwards.
      • So after e.g. 3 years of successful non-multitenancy implementation, there is no affordable way to implement multitenancy as additional feature, as multitenancy must be concerned at almost any business function and so almost any code function.
    • It might be cheaper, also with server-based applications, to start a new application instance for each tenant, even if there are “hundreds” of different tenants.

Patterns

Flexibilty by Patterns ( Patterns which enable to create flexible Software )

Some other important Patterns

Resources

Literature

Don't repeat yourself ( DRY ) vs. Write Everything Twice ( WET ) & Because What If I Need It Later ( BWIINIL )

Fundamental Modeling Concepts ( FMC )

Embedded Systems - The Evolution of System Design for Embedded Systems

  1. Assembly language.
  2. C.
  3. C++.
  4. Objectoriented Software design
  5. Advanced
    1. Interfaces instead of inheritance.
    2. State machines.
    3. Mockup.
    4. Application wireing.

Fully Communication Oriented Information Modeling ( FCO-IM )

Functional Flow Block Diagram ( FFBD ), extended Function Flow Block Diagram ( eFFBD )

ICONIX

"Imperative Programming" vs "Declarative Programming"

Old-fashioned "Structured Programming" aka "Imperative Programming"

Resources

Interface Description Language ( IDL )

Model Driven Architecture ( MDA ) & Dynamic System Initiative

Modelling SA/SD - Structured Analysis ( SA ) and Structured Design ( SD )

Object Oriented Design, Object Oriented Programming

Dependency inversion principle

Application Wireing Frameworks

Resources

Javascript - Concepts of Javascript

Object Calisthenics

Object-relational Mapping

Type Composition and Inheritance

Ports and Adapters

Resource-oriented Computing

Clean Software Installation

Sideloading

Installation with Signature

ITU-T Specification and Description Language (SDL)

SOLID ( S.O.L.I.D )

Specification by Example

SPES2020

Story Driven Modeling ( SDM )

Example "Mensch-Ärgere-Dich-Nicht"

  1. Textual use case description, of DE.Wikipedia "Mensch ärgere Dich nicht".
  2. Story Boarding (OOA) ( Test specification ) → Object diagram. # That's the new approach!
  3. Class diagram deviation ( OOD ).
  4. Behaviour deviation ( Coding ) → Activity Diagram. How may I change the object model, to get from one state to the next ? How may I proceed from one object ot the next object ? How do I generate behaviour for the objects ?
  5. Code generation.
  6. Validation ( Testing ).

Resources

Style Guides

Apple

    • Apple Developer "Mac OS X Reference Library" - “Guides. Conceptual and task-oriented information. Guides include overviews, tutorials, programming guides, server administration guides, and, for developer tools, user guides”.
  • Classical Pre-MacOSX ( MacOS9, MacOS8, MacOS7.. ) Style Guides.
    • “Apple Developer Connection - Apple's Developer Guides”.
    • “Macintosh Human Interface Guidelines”.
    • “Macintosh Toolbox Essentials”.

Atlassian

  • Atlassian Design Guidelines - “Design principles, components, patterns and guidance for building awesome Atlassian products and add-ons”

Microsoft

Test Driven Design ( TDD )

Twelve-Factor App

UML, SysML

Unsupported Software Development :-(

Big Ball of Mud :-(

Rogue Programming :-(

Usability

Use Case Planning ( Use Case Points, Use Case Point Method )

Literature

Resources

Forums, Newsgroups, Communities


When this document changes ! Site Navigation ( My Business ! My Topics ! Imprint / Contact ! Privacy Policy ! Keyword Index ! ! Google+ Publisher "hemmerling" )

 
en/systemdesign.html.txt · Last modified: 2017/12/11 17:54 (external edit) · []
Recent changes RSS feed Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki