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

Domain-driven design seems “straight-forward” when looking at green field development. Implementing that in an existing enterprise system, however, is daunting.
In this session we will go over some of the refactoring patterns that support this change and we will demonstrate the steps necessary to refactor a non-DDD SOA-based system using DDD approaches. We will talk about the kinds of decisions that have to be made, when they need to be made, and what those decisions look like in the grand scheme of your refactor.
Check out more of our talks at:
ndcsydney.com
www.ndcconferences.com/

[@luckyashnar2330]

Thank you, It was very engaging, clear and concise overview of how DDD could be applied. It helped me to understand the concept, and get some basic information in less than 1h.

[@jan5310]

The two mentioned talks can be found here: Implementing your first Event Driven Design - Sarah and Ann kzbin.info/www/bejne/pZSZmZWFpMiAl5Y Practical DDD with EF Core - Hossam Barakat kzbin.info/www/bejne/r6nXpId7ncdkapI

[@andrewferguson6901]

This presenters speaking style is very good for playing on 1.5x speed. he doesn't speak quickly then pause but instead has uniform space between sounds and it trims super nicely

[@lior279]

52:45 - "hippie language javascript" 😂🤣

[@evilsdexter5261]

Good talk, apart from that unnecessary comment about javascript, maybe it would be better to use "swing" to build UI's ... Anyway, what puzzles me about using the message queue is how do we make sure that the appropriate contexts handle all the messages that they should, how do we document that and share this info between various teams in charge of these? Let's say we have an order and an inventory bounded context. The order b.c. publishes a message with something has been ordered, which gets picked up by the inventory system and the system decrements the quantities. Now let's assume that something happened to that order and the order system publishes an order cancelled message. Again the inventory system is designed to pick up and handle that (incrementing back the quantities), so all is good. Now, after an year, we get this need to have partial cancellations, and we implement it in the order bc, thus the order system will now publish a different message, a partial order cancel... but what if the guys in the inventory context didn't implement it yet? This is a simple example, however, if you have a system with many many bounded contexts, this kind of desync will happen. How does one deal with this?

[@siddharth23able]

That is what the common messaging infra is about. Since it is common, each bounded context is aware of the changes introduced there. We need to keep the ubiquitous language updated(partial cancellation becomes part of ubiquitous language) and redefine the communication between bounded context. This is highlighted in the talk and this should help in keeping the system in sync.

[@bepkororoti8019]

Ahem, having a separate way to read and write, aka CQRS, can easily be applied to the whole system, what he probably meant to say is that using event sourcing as a top level architecture can be problematic because it's a lot of effort that doesn't pay off with many types of systems that don't really need custom code for very strong domain invariants, event replay, perfect auditing etc, say, CRUD systems, where the DB already enforces most of the modeling goals. Nothing new here, watch Jimmy Bogard's talks, he always has some interesting new insight that hasn't been regurgitated to death

[@mahbuburrahmanrahman2677]

Do you tell me Is it possible to control AC FAN dimmer (with zero cross detection) both By two Physical push BUtton (speed increasing and decreasing) manually and also By Blynk app slider button for controlling speed through wifi. I ask the question because facing very difficulties to write the code for integrating push button function with only wifi controlled code (By blunk app slider button) . do you know is it possible or not ?

[@AB-fp8xo]

Microservices have a lot more cons than pros. You will not be able to use transactions beyond a single microservice, latency of your app will be greatly increased, you will need a separate DevOps guy to monitor and administrate the entire infrastructure, development process will be much more complicated with microservices... etc etc etc. But at least after many companies failed at introducing microservices, now people started realizing how bad microservices are.

[@billthevestguydoessoftware8789]

Microservices require a different way of conceiving of your system. All of the problems you list are valid concerns, but I think every different system cares about them differently. For example, you mention transactions. The term "transaction" indicates a serialized aspect to persistence. However, there are other approaches that eliminate that need. If you don't use RDBMS, then all of a sudden saving one object to get its FK ID (the most common reason that I have seen transactions required) becomes meaningless. Are microservices more complex? Mehhh, perhaps, but I think a well-reasoned "monolithic" application is much harder to design. Except there, you can gloss over gaps in the ubiquitous language because "they are all sharing a domain anyway" where in microservices you have to be much more pragmatic about the boundaries between the services. So in that way, I guess I could say it is more complex simply because it makes it harder to cheat.

[@nasragiel]

@@billthevestguydoessoftware8789 thats a pretty good and pragmatig answer. :)

[@austin.valentine]

@@billthevestguydoessoftware8789 Also taking into account Conway's law, it seems that much of the complexity is due to actual business complexity and to some extent desired. Businesses get more complex as they try to increase market share and use resources to offer completely new products in completely different markets. Having the flexibility in your computer systems to maintain alignment with the business complexity is kind of a feature, not a bug. All said, it seems like spending less time on some things and more time on others, hopefully on more value-add business-related concerns rather than reevaluating a huge monolithic system for every small change.

[@Neghe89]

DDD is not equal to microservices

[@MrVipulLal]

Totally dry and theoretical chat. No examples used at all

[@yasser2768]

Will never work on AWS It's crappy and expensive And microservices honeymoon is a myth Monolithic design is still valid, it's all about how you design it

[@AB-fp8xo]

Couple of years ago there was a big hype around TDD and everyone wanted to use it. Now the hype is over and almost no company is using TDD. Microservices will meet the same fate as TDD.

[@billthevestguydoessoftware8789]

I have to disagree with you... Works perfectly on AWS (been there, done that - otherwise I wouldn't have done the talk ;-). What microservices offers is fine-tuned scalability. Do all applications worry about scale? Nope... In those cases "monolithic" design is still valid. If however, scalability is a concern, then microservices have to be on the table, because they allow you to scale different areas of your app differently. If one section of your monolithic application is overutilized (say reading the product list) you can simply scale that one microservice that does that work, rather than having to start up 2-3 more instances of your complete application. That's the fine tuned part - rather than scaling to the lowest common denominator, scale to each microservice based upon it's participation in the whole.

[@billthevestguydoessoftware8789]

@@AB-fp8xo TDD impacts the way that developers do their day-to-day work. I am seeing a lot of acceptance in new developers and others that don't have to change the way they work. Microservices are a different way to think about applications. I've been around for a while, so I remember that exact same statement about client-server, and then about web apps. Most modern applications that scale are built on microservices. Should they be used everywhere? nope...