Видео

Thank you!

Yes, the Java team recommends Optional is only used for return types. In return types, it is to make it explicit to the caller that they would need to handle a None case. For method arguments, they discouraged it, for a bunch of pragmatic reasons - if you google "java optional as method argument" there are some great stackoverflow discussions on the topic with for and against arguments. Personally, having familiarity in more functional languages, I'm very comfortable using a Maybe/Option type as an argument - but try to follow the Java recommendations/idiomatic approach in this demo. I actually don't recall using it as a method argument in this demo though - can you remind me where I may have done that?

@@ChrisSimonAu 25:03

​@@IvanRandomDude Great catch - thanks so much! I think the Java idiomatic thing to do here would be to not pass an Optional<Room> in, and instead just pass in a Room and have the controller look like: Course newCourse = roomRepository.findById(courseRequest.getRoomId()) .map(r -> Course.includeInCatalog(courseRequest.getName(), r)) .orElseThrow(() -> new ResponseStatusException(HttpStatus.BAD_REQUEST)); Keeping the functional/monadic style separate from the entity method. I'll update my repo for future demonstrations :)

Thanks!

Thanks!

Thanks! Great question - I think a DTO to define the payload of a REST resource request or response is a very useful pattern for at least 2 scenarios: 1. You want to have some private data on the domain model that you don't want exposed via the API 2. You want to ensure a consistent contract on the API but have the freedom to change your domain model. In this demo, it starts with just sending the domain model as the API response. However, the tests include their own copy of the API payload - so effectively, a DTO specifying the API Consumer expectation. If you modify the domain model such that it breaks the test, then that could be solved at that time by creating a DTO on the application isde and setting up a mapping.from the domain model. To further protect things, you should ensure the tests use 'strict' deserialisation - e.g. unexpected fields cause deserialisation failure.

Thanks for the comment - I agree - when I practice TDD in real life, it's much more of a winding route than this demo illustrates, with often more refactoring steps and sometimes backwards undos. However, with only 50 mins, my goal with this talk is to demonstrate 3 key things: 1. the value of the 'many more much smaller steps' approach to TDD 2. how approaches to domain modelling (such as event storming) can help with more valuable and simpler designs 3. how TDD as a general philosophy supports even large scale design changes To that end, each third of the talk is roughly about each point in sequence. And even then it feels like a very 'full' talk! But yes, I 100% agree with you and would love to do more demos that illustrate more 'real world TDD' :)

There are a number of technical mechanisms for "solving" the concurrency issue - transaction isolation level is potentially one, as are a variety of pessimistic and optimistic concurrency controls. They each have their tradeoffs, balancing throughput and waittimes. If one of those mechanisms was used, then as you point out, whichever way the concurrent activity is detected, the operation could be retried in a new transaction which would protect the business rule. In this case, cause one of the students to be told their enrolment was no longer possible. The point of that part of the talk wasn't really the particular mechanism but more to highlight that a deeper understanding of the domain can remove the concurrency risk all together - and lead to a better outcome as students are less likely to experience their enrolments failing and the education provider can service more students overall.

@@ChrisSimonAu Sure thing :) I just wanted to share that locking / versioning doesn't have to be implemented by a programmer (as this implementation will then have to be maintained), instead - features of the components that are already part of the system (database) could be used to achieve the desired behavior.

​@@IlyaDenisov Yes, it is possible to use database as your concurrency control mechanism and that is typically fine for small projects and prototypes, but if your application scales, you run into problems. For instance, you start having some long running transactions and because you have put everything inside "@Transactional", you soon enough run into lock wait timeouts and deadlocks. Also, think about what happens if at some point, you want to introduce some caching into your application, so that not every single request hits the database. Now that task has become significantly more difficult because you were relying on your reads and updates being in the same transaction boundary for your application's correctness. I am not saying that your approach is always incorrect, but keep in mind that every design decision has consequences.

​@@alexsmart2612 Good point. Yet I think this aspect (concurrency handling for the feature) should evolve incrementally in the same way as other aspects of the app, so that initial implementation that is suitable for the described logic and project state, could be as simple as transaction isolation levels. That kind-of resonates with the idea behind TDD approach highligthed by Chris in the video - engineer will benefit from maintaining a balance by doing only a small reasonable step at a time, instead of trying to build THE ULTIMATE SYSTEM from the start :)

​@@IlyaDenisov Once you have a million loc project with infrastructure and business logic concerns spread all over the place, it is an expensive hole to crawl yourself out of. While I completely agree with the general principle of "maintaining a balance", for me optimistic locking, keeping small transaction boundaries etc fall well within that reasonable balance. It is not all that hard to implement and maintain even for junior developers (after a brief training period). That the resulting code is typically much simpler and easier to reason about is an added bonus.

I'm not sure about the first question - there is an Enrolment entity, but it is in the Enroling vertical slice/feature folder. On the second question, I didn't have time to talk about the tradeoffs of those two approaches, but it's a good question. To start with, I find starting with IDs simpler as you can build up some of the functionality in this incremental style, even before the other entity exists. Later, when it does exist you could refactor to use a reference object instead of an ID - if it makes sense. As to why it might or might not make sense - this is a big topic that relates to transactional consistency boundaries (aka aggregates), lazy vs eager loading and read vs write models. It's hard to summarise in a youtube comment but if you google "ddd reference object vs Id" you will find much discussion about it! In particular google "vaughn Vernon aggregate design rule 3" which should turn up some papers that take an in depth look at this pattern.

If you apply DDD “by the book” then it is not allowed for one aggregate root to keep a strong reference to another aggregate root. However, it is allowed to store the unique identifier of that other aggregate root (weak reference). In the demo of Chris, Student, Course and Enrollment are all separate aggregate roots I believe. It is also said that in a single transaction, your are not allowed to update multiple aggregate roots. If one would store a strong reference to another aggregate root; it would be possible to update multiple aggregate roots which thus violates the principle. If 1 aggregate is interested in changes that occur in another aggregate; you should implement domain events. The other aggregate root should have a domain event listener that reacts on those events in its own transaction. I hope that makes sense :)

"Why Enrolment has studentId and courseId instead of an instance of those classes" Because if you implement with instances your changes you apply are not atomic anymore and concurrent updates will be hard. Imagine someone at the same time changes something about course (e.g. professor updating curriculum) and student at the same moment updates his personal info. When both of them try to save, it will fail! Even though their updates have nothing to do with each other. Keeping them separated and only related by id, allows for smaller changes to reason about. Which is another pro of this solution, because the example is simple right now, but all of the software will get more and more complex, have more business cases. Having them together will make it complex to reason about each of them and we have limited brain capacity

Thanks!