Mike Wojtyna
Technical Business Partner | Consultant | Trainer
Bydgoszcz, Poland
Actions
I'm a software architect with a passion for creating great products. Domain-driven design & Test-driven development are some of my favorite tools. My code is clean and easy to modify, thanks to the modular, loosely coupled design achieved by continuous TDD iterations backed by a deep understanding of business requirements.
I'm also a professional consultant and trainer. In my free time I create online courses and write articles about software development, DDD and clean code.
Check out how I can help you
http://www.wojtyna.pl
Links
Area of Expertise
Topics
Archetypes - your secret superpower
Imagine jumping into a new project. In a very short time you start asking meaningful questions, understand the business, and model it correctly. Somehow you just feel what’s right. You manage to solve some of the problems the team was facing for months. You suggest improvements that can benefit your clients tremendously. All within the first few weeks. Some team members may admire you, while others might make accusations that you are cheating or faking your abilities, or that you possess some special superpowers. Sounds like a fairy tale? During this presentation I’m going to show you how you can utilize archetypes to immediately recognize the business patterns, make right modeling decisions and astonish your fellow team members.
Domain Experiments
Our clients don't know what they need.
This happens because no one can foresee the future.
Requirements will evolve and change rapidly over the lifecycle of the project. That's why we need to constantly refine systems.
We can keep building and discarding prototypes, but it's extremely costly.
Often we can't afford to rewrite everything from scratch only because some new domain insights were discovered.
This eventually leads to a mismatched model.
Is there another way?
We can focus on domain only and refine our model through examples, until we find the right conceptual contours (http://ddd.fed.wiki.org/view/welcome-visitors/view/conceptual-contours).
Each such iteration of the model is a kind of experiment challenging the upfront decisions.
During this presentation I'm going to show how you can use example mapping combined with business-oriented TDD to be able to run rapid experiments directly on the domain model, without a need to rewrite the system again.
Becoming a Technical Business Partner
We often consider business and developers as separate teams. The “Business” part needs something, while “Developers” implement it. This clearly defines the Customer-Supplier relationship at best and Conformist at worst. In these relationships Business acts as Upstream, while Developers as Downstream. Doesn’t sound like the best option when developing custom solutions, does it? I’m going to show you how to upgrade this relationship into Partnership.
During this presentation I’ll show you how you can make your first step into becoming a Technical Business Partner. Technical Business Partner is a business-oriented engineer with deep technological expertise. Instead of just implementing stuff correctly, TBP understands the business and therefore is able to suggest improvements in the business model or any other aspects of running the company. This approach allows us to build better models, increase velocity of the development and focus on what’s really important instead of wasting time and energy on technological bikeshedding.
Take your first step to become a Technical Business Partner!
My design is better than yours: bridging the gap between tactical modeling and business
Engineers have a tendency to create emotional connections with their models. At best, this can end up with a lot of pointless discussions, at worst escalate to nearly-religious wars in the defense of "the only right model”. So… Are we doomed to repeat these nonsensical fights all the time? Fortunately, there’s an entity that can decide which model is better. It’s called business.
During this presentation I’m going to show you how you can avoid analysis paralysis, pointless discussions, common design pitfalls and creating overengineered, often totally unnecessary code. Together, we’ll bridge the gap between tactical modeling and true business drivers.
Domain-driven architecture
We can't avoid essential complexity when creating architecture. What we can avoid, though, is the accidental complexity. During this talk I'll show you how to align architecture & strategic DDD to focus only on essential complexity instead of wasting time on technological bikeshedding. You will learn about architectural meta-models driven by domain, how to reliably compare architectures and how to make right design decisions that are respected by application code.
Mike Wojtyna
Technical Business Partner | Consultant | Trainer
Bydgoszcz, Poland
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top