Bill Penberthy

Information & Communications Technology

Government, Social Sector & Education

Business & Management

Media & Information

Software Architecture Software Development Trust Leadership

Seattle, Washington, United States

Bill Penberthy

Curmudgeonly .NET Advocate in a Modern Apps world

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.

Current sessions

Supporting eventual consistency in a microservice world

One of the most complex areas in designing microservices is the combination of microservices, messaging, and data responsibility. How does it work if more than one microservice is interested in the same data? In this session we will go over the most effective approaches and discuss the kinds of use cases that each support.


Software and Database Refactor Patterns

Many of us are working on enhancing and maintaining systems that have some longevity. Changing these systems in any meaningful manner is dangerous. I learned during my years as a consultant that one of the most common problems that companies have when trying to revitalize applications is understanding where to start. In this session we will talk about various software and database refactor patterns that are designed to limit that danger, ensure forethought and planning around any major refactoring efforts, and give confidence around the likelihood of success for a refactoring.

We will talk about various reasons for refactoring an application and discuss those patterns commonly used to support that refactor. As part of this discussion we will also talk about external factors, such as team size and experience, can affect the success around various pattern implementations.


Modernizing an existing system to take a more domain-driven approach

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.


Port that .NET Framework application to .NET 5

.NET 5 represents a new era within the .NET ecosystem. New development on the .NET Framework has ended, and while it is still a viable application framework, the writing is definitely on the wall as there is no reason that any new development projects would use the v4.x .NET Framework. Instead, they would most likely be on .NET 5 or .NET Core 3.1. This could end up with projects within a company being scattered across various development frameworks as your team manages both current applications and new systems.

In this session we will look at how to port your .NET Framework application. We will use the Porting Assistant for .NET (an open source AWS-created application" to evaluate the level of effort needed to convert the applications as well as work through several of the most common porting issues and concerns.


Developing and deploying a distributed system on AWS

In this 2 day long session we will build a web based UI that interacts with with multiple microservices. The UI will be relatively simple and plain - don't come to this session with any expectations around cutting edge UI implementations! We will instead be focusing on the interactions between the UI layer and the microservices, and especially the internals of how those microservices are designed and implemented, how persistence is managed, and how they communicate with each other.

As we build out the various subsystems we will go through different approaches for building and deploying the applications onto AWS. We will configure the messaging system and the various databases so that each microservice can be responsible for maintaining its own data. We will then tie them all together, run the system as a whole, and watch the interactions as the various subsystems communicate with each other based upon actions taken in the UI.

All participants will be given enough AWS credit so that they can replicate the deployment steps in their own AWS account without any risk.


What happens with a poorly defined domain?

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.


Evolving from TDD to BDD and how it increases quality

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


Building Trust as a Development Organization

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.


Modernizing an existing system to take a more domain-driven approach

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.


Microservices and data persistence

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:
- Relational\SQL
- Key\Value
- Document
- Graph
- In Memory
- Time Series
- Ledger


Past and future events

Caribbean Developers Conference 2021

29 Sep - 2 Oct 2021
Punta Cana, La Altagracia, Dominican Republic

NDC London 2021

25 Jan - 29 Jan 2021
London, England, United Kingdom