Como você usa padrões de projeto e arquitetura de software em sistemas complexos?

One thing I've found helpful to identify the problem domain is by explaining the system. For me writing is the best way to explain. I prepare a map of objects or entities while thinking thoroughly and writing the explanation. Drawing the map helps defining the entities hence, help me figure out the problem.

Capture the domain problem will be the first action to take, define the escenarios, use cases, possible bottlenecks and write it in a design document before starting coding it's usually the best way to start.

Design patterns and software architecture play a pivotal role in the development of complex systems. We need to keep the following points in consideration 1. Understand the Problem Domain 2. Choose the Right Architecture 3. Identify Key Components and Modules 4. Apply Design Patterns 5. Separate Concerns 6. Define Interfaces 7. Ensure Loose Coupling 8. Use Layered Architecture 9. Handle Error and Exception Scenarios 10. Document the Architecture 11. Consider Scalability and Performance 12. Keep Security in Mind 13. Test and Validate 14. Monitor and Maintain 15. Adapt to Changes

All patterns are wrong, but some are useful. This is a paraphrase of the famous quote by George Box: 'All models are wrong, but some are useful.

Identifying the problem (or real requirement) is core of everything. There should be cross validation of problem understanding with stakeholders. Its necessary that the problem should be also analyzed if its a pattern and some other departments / workstreams already have a solution for it.

It’s important to understand that each architecture pattern/style has its own strengths and weaknesses, and the “best” pattern really depends on the specific needs and requirements of the app being developed. So, it’s really not fair to compare one architectural pattern to another and say that one is better than the other. Instead, we should focus on understanding the key principles and concepts behind each architectural pattern and use that knowledge to choose the most appropriate pattern for the specific project. One more thing is that each architecture pattern has a unique set of best practices and coding standards that need to be followed to ensure that the codebase is well-structured and maintainable.

I advocate for the utilization of a microservices event-driven architecture. It's crucial, however, to strike a balance by maintaining a manageable number of microservices to uphold the integrity of your chosen design. Achieving this balance involves avoiding excessive complexity in your initial design and adapting the services to your specific needs, effectively scaling and breaking them down when necessary. This approach ensures that your architecture remains efficient and aligned with its intended purpose.

I find it helpful to make comparison tables/lists to see the pros and cons of different styles in a particular scenario. What could the caveats be? What downsides? What does it solve? It's good to come up with a list of questions like that to answer them and see if it fits the need. So, the list could be going like this: - what it will solve - how we scale it - how traceable it is - how testable it is - how reliable the solution would turn out - what the flaws are - what the strong sides are - how to maintain and support it in the future - how easy it is to extend it - possible SLAs There could be more questions, something that will depend on the project. But usually answering these will help to see if the style is applicable.

From a programmer to programmer perspective, applying design patterns 2 prerequisites: 1) Good understanding of problems & respective solutions described in Gang of Four patterns & Architectural patterns in programming language of your choice (Good examples include UML notations /use cases/real world scenario/Framework scenario) - helps our mind to get trained in multiple perspectives about an appropriate solution when we encounter a problem. 2) When analyzing the problem, think from a big picture in addition to understanding the original problem - digest and write up in a white board (or) mind map and assess the solution to come to a conclusion.

Applying design patterns involves recognizing recurring problems in software development and using established, proven solutions to address them. To apply a design pattern effectively, you first need to identify the problem or scenario in your codebase that aligns with the pattern. Once you've pinpointed a suitable situation, you should understand the intricacies of the pattern and how it can be adapted to your specific context. Then, you implement the pattern in your code, adhering to its structure and principles. It's important to remember that design patterns are not one-size-fits-all solutions; they serve as templates that can be customized to meet the unique requirements of your project.

Design patterns have to be carefully selected by weighing their pros and cons by looking at short term vs long-term impact, direct and indirect impact to related systems/components/applications, impact on the operational aspect, impact on human resources and non human resources

Design patterns are not a cure for all. Hence, approach it carefully. Don't overuse them, and don't use them just because it's considered a common practice. Find reasons why they are to be applied. One of the perspectives I have is to see how extendable I want to create something. Or if there is a complex part of the system, maybe design patterns will help other engineers to maintain, support it, or extend it more easily. Some design patterns can help the operational aspects, and some help engineers to better perceive the code. Just ask yourself what you solve by this. If the answer is "I just want to use design patterns" you are likely overengineering things.

Apply design patterns, or reusable solutions to common problems that occur within a given context. Design patterns provide a common language, a set of best practices, and a way of abstracting and reusing the system's functionality and behavior. Some common design patterns are creational, structural, behavioral, and concurrency patterns. You can use design patterns to refine the system's architecture, to address specific problems or challenges, and to improve the system's quality attributes.

Using a design pattern itself is a form of communication. Developers with various domain background may take time to understand a new domain, but a piece of software written using a known pattern is easier for them to grasp and interpret.

As the software evolves, design patterns continue to play a vital role in ensuring maintainability and extensibility. When making changes to the codebase, evaluate existing design patterns and consider whether new patterns need to be introduced or existing ones modified to accommodate the evolving requirements. Document the use of design patterns and architectural decisions to assist future developers in understanding the system's structure. In the design phase, select and apply design patterns that address specific design challenges. These patterns help in creating well-structured and maintainable solutions.

Effective documentation and communication of design patterns and software architecture are crucial for maintaining and scaling software systems. This process typically begins with creating architectural overviews that offer a high-level perspective on the system's structure, supplemented by UML diagrams and written descriptions. A catalog of design patterns should be maintained, explaining their application and relevance within the system, often including code snippets for reference. Leveraging documentation tools and platforms, as well as integrating code comments within the source code, helps ensure that the knowledge about the architecture and design patterns remains accessible and comprehensible to the development team.

Occasionally, there might be situations where midway during the development / scaling the project, there might be suggestions to redesign (part of) the project. Most of the time, this is averted by having prior experience / experienced team members, but having different options discussed and documented helps in understanding rationale behind the decisions that were taken. Further, with time, details and rationale might be forgotten or responsibilities might be handed over. Having things discussed with the team and documented would help a long way during those times.

The documentation of the design should not be too complex, meaning don't try to include everything in one but have clear segregation between functional design, High level technical design, infrastructure design and low level design. Keep all the documents well indexed and searchable. The biggest problem with documents is with stale documents they cause more harm than not having any documentation.

From a software product development perspective, this is a continuous and iterative process. Any new feature integration / changes / scaling should be done with the whole project architecture in mind. A thorough understanding and mind visualization is very important during all stages of development.

Undergoing this iterative activity is inevitable weather it’s a vanilla new system to be delivered or - typically- for systems already in production. Two practices are easing this phase processes; (1) Agile SDLC would offer more ease in redesign and furthermore re-engineering if required more than monolithic/waterfall ones. (2) Microservice architecture paradigms with a proper service-aware build-ups. Trying to avoid pushing away these activities may lead to more harm than benefit, like falling in analysis paralysis

"Write the tests you wish you had. If you don't, you will eventually break something while refactoring. Then you'll get bad feelings about refactoring and stop doing it so much. Then your designs will deteriorate. You'll be fired. Your dog will leave you. You will stop paying attention to your nutrition. Your teeth will go bad. So, to keep your teeth healthy, retroactively test before refactoring." — K. Beck, TDD: By Example Good tests are important even though they may take more time. For long-term systems, it's essential to have good test coverage so it may allow safer refactoring. Moreover, good testing practices allow the introduction of design patterns, refactoring, etc, in later stages much safer.

It's not iterative as much as a changing environment for people who know. It is a dynamic as political change for most companies, which means what? It means that your prototype, reviews, metrics, testing, simulation and everything else in this article must be done with the expertise of a presidential campaign analyst, so good luck on that. A few obvious examples of dynamically changing architecture if you have expertise, security, interfaces and scalability for systems that change and grow and/or shrink week by week if that is possible.

Software architecture and design patterns are used to analysis a complex business requirements into sub modules and apply the design elements such as UML, use cases, sequence diagram, algorithms to break down the system into sub systems, modules and get it constructed. The design patterns help in apply the non-functional requirements such as performance, scalability, reusability, security, maintainability, accessibility to the system that is build. Design principles such as SOLID is used to apply the rules or principles to get the system constructed in a such a manner so that it follows the object orientation, dependency inversion concepts into the system.

I can't say enough about practicing the use of software design patterns or at least thinking through how you would eliminate code repetition before, during and after you start implementing the patterns. You gain your own opinions that are valid about each one and concerns, stipulations and insights about when to use each one. No one can take that away from you, and in that way you are going to do nothing but gain relevance in your field when people ask you (if they ask). I am first reflective and then financial analysis about patterns. Little else matters to me and this approach, for me and probably 99% of the software engineering field, which is why you are going to find so much written about cute examples and then some accounting.

I keep saying "don't swallow the solution, digest the problem first". Selecting Products should not be the aim of the design but should always think of all possible integration and customization requirements which comes along with any product.

At the end of the day is about the business needs, sustenance and ecosystem fit, flexible for change. Keep things simple , adaptable, good enough is one the best approach to go

The initial design may not be always perfect keeping in mind the present and future requirements. Hence make the design extensible so that it can adapt to future changes. Focus on basic building blocks of the design and harden it as much as possible so that when new changes are incorporated the impact on the overall design would be less as building blocks are SOLID.

Design patterns provide a structured and consistent approach to team collaboration. They assist both team members and me in comprehending the project's organization and locating specific elements without unnecessary time spendings. Everything is well-organized and has its designated place. I don't recommend employing overly complex, multi-layered architectures, as they can result in unnecessary complexities, even for relatively straightforward logic. Simplicity remains the guiding principle.