Software Architecture Software Development Trust Leadership
Seattle, Washington, United States
With over 25 years in software development (almost 15 of which is .NET), Dr. Bill brings a pragmatic (curmudgeonly?) approach to software development. With much of that time spent in consulting, he has worked on many different projects and used many different designs and approaches. He recently switched to the dark side and uses his development experience in a product management role where he acts as a .NET developer advocate with AWS, helping AWS to build a better and more rich .NET developer experience.
The most important part of DDD is the domain. It says so right in the name. Getting it right is important, and not as easy it may seem. This session talks about a couple of instances where domains were defined in ways that were arguably incorrect and, of course, this didn't become obvious until deep into the project.
Changing a system's design because you got it wrong is not easy. However, there are times that it will be necessary. In this session, we will talk about how to identify problem domains, how to understand the correct domains, and discuss the implementation of refactoring strategies to use when making this change.
Amazon Cognito is a service that provides a secure user directory that scales to hundreds of millions of users. Take advantage of a serverless, managed system to securely manage authentication across multiple identity providers. In this session we will demonstrate using Cognito in both ASP.NET and ASP.NET Core applications.
The cloud in general, and cloud services specifically, is an important consideration when looking towards the future and technology. This consideration reaches down to the skills level. This workshop will help satisfy those skills needs by providing you real-life, hands-on, examples using Amazon Web Services to solve business problems. Expect a mixture of deep-dive into the code as well as high-level discussions of “how-to” and “what-if”.
This workshop will cover:
• Identity and access management and security – keeping it safe
• AWS Toolkit and SDKs – working with AWS services within the IDE
• “Simple” web apps – build and deploy a web application into a VM or a container
• Managed data and\or purpose-built databases - learn to use both managed data and purpose-built database systems
• Building functions to run Serverless – why rent a whole or partial machine when you can break it down by the processing period
• Tying Serverless functions together with an API Gateway
• Real-world web application – pull it all together for those applications that are more real world
TDD, or test-driven development, is a sexy acronym that has the advantage of adding real value. However, behavior-driven development, BDD, is even sexier, and adds even more value. In this talk we discuss how moving from a TDD to a BDD approach increases both quality and developer effectiveness.
Behavior-driven development is an extension of test-driven development. It came about because common implementations of TDD are problematic, especially when looking at the context of the tests that are being created and how common it is to define tests that are either too high level or too low level to actually drive quality in the code. BDD is a way to define a more specific set of boundaries around the tests and how they are defined that will help drive quality and consistency.
Since BDD is basically an extension of TDD, it would seem that this should be a straight-forward change. It is not. Bringing BDD into a software development organization requires a level of stakeholder inclusion that is frightening to many development organizations. This workshop will go over: - common test-driven development practices - the difference between TDD and BDD - the changes necessary to be successful at BDD - how BDD drives quality improvement - how BDD helps you have those hard conversations - when you probably don’t need to change what you are doing
There are countless anecdotes about trust and development organizations; many of which are negative. This is well recognized and most organizations have taken steps to try and remedy that problem. However, many of those approaches either fail or are not as successful as hoped. In this session, we will go through the different aspects of trust and how to take advantage of these aspects to enhance trust in inter-departmental relationships.
To do this, we will cover:
- What is trust, really?
- Why do we care about trust?
- What builds trust?
- What hurts trust?
- How do you repair trust?
My doctoral dissertation had a very strong focus on trust, and the more I learned about trust the more I realized that it was how I was able to successfully build effective development teams. This presentation has theory, real-world application of that theory, and an interactive component to help that participants understand their own feelings on trust.
Domain-driven design seems “straight-forward” when looking at green field development. Implementing that in an existing enterprise system, however, is daunting. In this workshop we will demonstrate the steps necessary in refactoring a non-DDD SOA-based system using DDD approaches, especially Command-Query Responsibility Segregation (CQRS) and Event Sourcing patterns.
The use of a service-oriented architecture is not new. There are thousands of existing enterprise systems that are built using SOA. This would typically look like a set of “client applications” that talk to a set of “back-end services” that were designed using a one-size-fits-all approach, where the representation of a persisted object is a union of all the business needs. The growth in domain-driven design shows how that may not be the best approach.
This session will be a dive into the process of modernizing a SOA-based enterprise system to support a DDD approach. We will talk about what this looks like at a high level and then demonstrate how this is supported by using Command-Query Responsibility Segregation (CQRS) and Event Sourcing.
Simply put, CQRS is an approach where different models are used when reading information than is used when updating that information. This approach becomes especially important as designs start being domain-driven, because each participant in the enterprise may have a different representation of that information. These different representations would be best managed with separate models. As part of this session, we will demonstrate (sometimes in code):
- What a non-CQRS approach looks like (current state)
- What a CQRS approach looks like (new state)
- How you manage data conversion
- Why we would take this approach
- How to tell when you have gone wrong
Event sourcing is an approach where all of the changes to application state are stored as a list, or sequence, of events. As part of this session we will walk through (sometimes in code):
- How event sourcing fits into DDD
- How this need is managed now (current state)
- What the implementation looks like
- How you manage the conversion
- How you can evaluate the effectiveness
Lastly, we will walk through how these changes fit into the overall modernization strategy.
Companies that care about living and working in a multi-lingual society need to be able to participate across multiple languages and abilities. We, as an industry, tend to look at accessibility and language translation as being two completely different problems. This is not completely accurate; as they both address a common need; the ability to provide information.
In this session we will demonstrate how machine translation and text-to-speech can work together to provide a more rich way to provide information. We will show how user interface cues and current cloud technology can partner together in enabling visitors to your website to better understand and take advantage of your information.
When building applications in a pure microservices architecture you have the luxury of flexibility around how you persist the data. Rather than being forced into a database system that tries to support all of your cross-domain use cases, you can choose a data persistence strategy that makes the most sense for that microservice. Sometimes that could be SQL Server or other RDBMS, other times it may be some other approach.
In this session will take a look at the major data persistence technologies that are available and discuss the kinds of use cases where they each make sense. The technologies that we will discuss include:
- In Memory
- Time Series
29 Sep 2021 - 2 Oct 2021
Punta Cana, La Altagracia, Dominican Republic