What are the most important design frameworks for a Systems Designer?

A Systems Designer needs battle tested arsenal: CAP theorem (Consistency, Availability, and Partition Tolerance) - The foundation for resilient and scalable systems. Embracing CQRS (for testing how efficient the dataflows are). However my personal favorites are - Zachmann Architecture Framework (ZAF my personal favorite) - Think big picture, (data, function, network, etc.) for a holistic understanding. Microservices Architecture: Breaking down monoliths into independent, self-contained services for agility and maintainability. Other frameworks are Event Driven Architecture (EDA) and Domain Driven Designs (DDD) which are bonus picks to adapt to real time changes. Once we mix, match and adapt the above concepts - we get A best dish!

Independientemente del framework que se utilice, cada uno tiene sus bondades y debilidades, se debe utilizar el que más se adapte a tus requerimientos de negocio. Es necesario poseer un conocimiento del negocio en cuanto a dimensión y procesos, bajo un enfoque sistémico, además, saber la oportunidad o problema a resolver, así como los beneficios a obtener

"There are downsides to everything, there are unintended consequences to everything" In software development, systems thinking is about understanding and building software together with your team to achieve business outcomes that are in alignment with what the organization wants to achieve. If we use a car metaphor, we could say that: Systems thinking is like switching to a rear-view mirror and looking at the whole picture. While object-oriented programming puts us into the driver’s seat and limits our vision to what’s in front of us. It’s unreasonable to be successful in one part without being familiar with the other.

There are numerous design frameworks for systems design. It all depends on the domain and context. Moreover, sometimes fashion influences, as, for example, in recent years microservices. They are often applied where they are absolutely unnecessary or applied incorrectly, which indicates that they were applied without trying to solve the problem that microservices actually solve. In my opinion, one of the most important concepts is coupling & cohesion. Understanding the difference provides the right direction for the development of application architecture.

Los marcos de dise?o más importantes para un dise?ador de sistemas incluyen el Modelo Vista Controlador (MVC) para separar la lógica de presentación, el Patrón de Dise?o de Capas para modularidad y escalabilidad, el Dise?o Orientado a Objetos (OOD) para modelar entidades y relaciones, y el Dise?o Centrado en el Usuario (UCD) para crear sistemas intuitivos y centrados en el usuario. Además, los principios SOLID y el dise?o de API RESTful son fundamentales para la mantenibilidad y la interoperabilidad.

Interpretation and creativity make art. It has 5 stages which are: Empathize, Define, Ideate, Prototype, Test. In Software Development How we use in Software Development: Empathize(User Research): Understand users deeply by gathering insights into their needs, desires, and challenges. Define(User Personas): Specify the problem to address and the user pain points the software should alleviate. Ideate(User Stories): Brainstorm creative solutions to the defined problem. Prototype (Wireframes and Prototypes): Develop early versions of the software for testing and feedback. Test (Usability Testing): Refine the prototype based on user feedback, ensuring user-friendliness.

For a Systems Designer, mastering key design frameworks is paramount. Systems Thinking: Understanding the interconnectedness of components within a system is fundamental. Design Thinking: Empathizing with users, defining problems, and iterating solutions is pivotal. Agile Methodology: Embracing adaptability and collaboration ensures project success. Service Design: Crafting seamless experiences aligns user needs with business goals. Human-Centered Design: Prioritizing user insights drives impactful solutions.

Formation of a Ubiqoutous Language among different stakeholders of your project is also an important part of domain driven design which helps you to draw common understanding, Reduced Ambiguity, Faster Development, Alignment of Stakeholders, Improved collaboration, and Maintainable Codebase.

Focus on Business Capabilities: Business microservices are designed around business capabilities and domains. Each service corresponds to a business function or a set of closely related business activities. This approach is aligned with Domain-Driven Design (DDD) principles, which emphasize the importance of modeling services based on the business domain.

Domain-driven design (DDD) is a smart way of software design approach : The primary goal is to capture and model the intricate business logic and concepts, emphasizing understanding over technical implementation details. DDD promotes the creation of a shared understanding between technical and non-technical stakeholders by using a common language based on the domain. By centralizing the business logic into a distinct layer, DDD enables independence and autonomy for this critical aspect of the system. This decoupling ensures that changes in other components or technologies won't significantly impact the core business functionality, leading to a more maintainable, scalable, and adaptable system that directly serves the goals of the business.

.NET provides a robust foundation for building scalable and reliable applications, supported by its design for building microservices, containerization support, asynchronous programming models, and comprehensive diagnostics and error handling features. Leveraging these capabilities and adhering to best practices in development, deployment, and operation can significantly enhance the scalability and reliability of .NET applications.

Even when you lay out the solution for best availability: Do not forget plan B and C. The question is not "will it happen" the question is "what to do when it happens".

.NET Core provides a robust framework for building secure, scalable, and reliable applications. By following best practices for secure design, development, and deployment, and leveraging both .NET Core's built-in features and external tools, you can create applications that not only meet functional requirements but also adhere to high standards of security and privacy. Data Encryption Authentication and Authorization Dependency Management Static Code Analysis CI/CD Security Dynamic Security Testing Firewalls and Network Security Groups Application Gateways and Web Application Firewalls (WAF) Data Protection API Elastic Scalability Health Checks Logging and Monitoring Identity and Access Management (IAM)

OWASP top ten provides a list of the most critical web application security risks and serves as a guide for building secure systems.

This is one of the most ignored parts of the huge NFR (non functional requirements) chapter during the setup phase. In any later phase / sprints many other constraints will pop up as well. In every real project you have to compromise for many reasons, that may be time, cost or resource constraints, legaly binding requirements and othres. There are too many reasons that cannot be ignored. Not beeing aware that you (have to) honor these constraints will make your live harder then necessary.

Important System Design Frameworks Modular Design: Focuses on breaking down the system into smaller, manageable, and interchangeable modules that can be developed, tested, and updated independently Microservices Architecture: A variant of the modular design, specifically for developing scalable and flexible software applications Domain-Driven Design (DDD): Emphasizes understanding the business domain and building software that reflects and evolves with the business Model-View-Controller (MVC): Separates the application into three main components: the model (data), the view (user interface), and the controller (business logic) Service-Oriented Architecture (SOA): Focuses on designing software components as interoperable services

I adopted the atomic methodology. Atomic methodology is composed of four distinct stages working together to create interface design systems in a more deliberate and hierarchical way: IONS -> are styleguides and design tokens. ATOMS -> are the most basic components like a button. MOLECULES -> the more complex components ORGANISMS -> are the output final modules.

If you are building a SaaS, 12 factor app is the de facto standard and my personal favourite. It promotes scalability, portability, and resilience by emphasizing principles like declarative configurations, disposable processes, and isolation of dependencies.

The most important lessons that I had to learn the hard way is: - Never ever design an "alien", always keep in mind who is actually using and running the final system. (the one linux in a win infrastructure will not work out in the long run) - Actively avoid thinking about how to solve something when you are gathering requirements it will cloud your view on possible alternatives. By the way, I use interface driven design: Cut the problem into data domains (not logical domains) and assess each resulting module as "already existing" black box. When this works out design each module as seperately as possible.