At its heart, much of Domain-Driven Design is all about object-oriented design. The challenge with elegant designs is that they all start out ugly. But our domain objects don't need to stay as anemic, data-centric property bags. With a small set of well-honed refactoring techniques, we can turn an ugly domain model into a wicked domain model, where our business objects respect boundaries, take our commands, and never, ever find themselves in a bad state.
For too long we've lived under the tyranny of n-tier architectures. Building systems with complicated abstractions, needless indirection and more mocks in our tests than a comedy special. But there is a better way - thinking in terms of architectures of vertical slices instead horizontal layers. Once we embrace slices over layers, we open ourselves to a new, simpler architecture, changing how we build, organize and deploy systems.
Tests are a good thing, right? But how much should we test? What's not enough? What's too much? What should we test, and when?
In this talk, we'll look at the many levels of testing, from the outermost UI tests to unit tests, what works well, what doesn't work well. We'll look at functional testing, subcutaneous testing, integration and unit testing and where and why we would want to do each. We'll arrive at a testing strategy for the sane without retreating into dogma by looking at real-world examples of how testing strategies differ per environment and team.
At the end, you feel the fulfillment of a customized, holistic testing strategy that works for you and your team.
A key tenet of microservice architecture is autonomy. This is all well and good when the business users dutifully follow Conway's law and rarely if ever use multiple applications from multiple services. But it can get worse, much worse, where we have a single application needing to expose information and capabilities through a single, consistent window. But those that do not learn history are doomed to repeat it, and we certainly do not want to repeat the same mistakes that felled SOA.
In this session, we'll look at the common reasons why we need to build composite applications, and some of the ways we can avoid doing so. As we continue, we'll look at integration patterns from a number of tiers, from the database up to the UI, examining patterns, techniques, and frameworks that close the last mile of microservices to build a maintainable, autotonomy-embracing compositional UI.
ORMs, the necessary evil, the so-called "Vietnam of computer science", the despised of DBAs everywhere. Much of the ORM hate comes from just bad usage of ORMs. In this session, we'll learn ORM anti-patterns and see what successful ORM usage looks like.
Heads up: the shoutbox will be retiring soon. It’s tired of working, and can’t wait to relax. You can still send a message to the channel owner, though!
