My notes on “Refactoring from Anemic Domain Model” by Vladimir Khorikov

This post is just to share my notes on the course “Refactoring from Anemic Domain Model Towards a Rich One” by Vladimir Khorikov.
https://app.pluralsight.com/library/courses/refactoring-anemic-domain-model

Module #2 – Introduction
– Problems with an anemic domain model: discoverability of operations, potential duplication, lack of encapsulation.
– Encapsulation is about protecting data integrity (no operation should be able to violate the invariants of a class, an aggregate). Protecting you from doing something incorrectly.
– Encapsulation is so important to maintain because without it we can’t cope with the increasing complexity of the code base (slows down development, increases the number of bugs).
– Anemic domain model always means the lack of encapsulation.
– If classes with data do not impose any restriction, the services with operations are the ones that should know how to keep the integrity and always remember to do it (potential duplication).
– An anemic model can be adequate for small projects that are not going to be developed for a long time. Also, different bounded contexts can have different needs.
– Anemic Domain Model and Functional Programming?. FP encourages immutable data structures and operations separated from them. Vladimir mentions that with FP immutability there is no need to worry about corruption of internal state, hence FP does not suffer from the lack of encapsulation. It suffers from discoverability of operations.
– In my experience I believe that immutability alone does not prevent us from breaking the invariants, an operation can’t change an object but can return a new copy changing one property in a way that breaks integrity. To solve that issue I would say that we should always use a constructor (which enforces invariants) to instantiate objects and not use the cloning mechanism provided by the language to bypass invariants validation.
Continue reading “My notes on “Refactoring from Anemic Domain Model” by Vladimir Khorikov”

My notes on the video course “CQRS in Practice” by Vladimir Khorikov.

I completed the course and I sincerely recommend it to anybody that wants to learn more about the Command Query Responsibility Segregation (CQRS) pattern and Domain-Driven Design (DDD) in general.

The course does not cover Event Sourcing (ES), what I like because allows learning CQRS in-depth avoiding getting confused with the most advanced CQRS+ES or getting advice that only applies when ES is been used.
That said, I would love if Vladimir can expand his DDD course series with a Event Sourcing course ;-).

Vladimir introduces all the concepts in a good progression, by layers (API, Domain, Database) and complexity, reminding us that there is no need to apply a full CQRS pattern to start getting benefits from it.

My notes:

Module #1 – Introduction
– With CQRS instead of having one unified model we have two: one for reads and another for writes.

Module #3 – Refactoring Towards a Task-based Interface
– Task-based Interface vs CRUD-based Interface.
– I found really good and realistic the example Vladimir uses, a legacy system exposing a single update endpoint is used by the UI for diverse uses cases (edit personal info, enrolling/disenrolling, transferring student), but nothing is explicit in the API side. What is there is a huge update method doing multiple things. The video shows how to split and refactor it away from a CRUD API to a task-based interface.
– Task-based interface involves not only the API also the UI.

Module #4 – Segregating Commands and Queries
– The terms Command and Query are overloaded, they mean command or query method in the context of CQS but just a data class in the context of CQRS.
– The objects representing our Commands and Queries belong to the Domain Model, as the Domain Events do (all 3 are “messages”). What does not belong to the domain layer are the Handlers that are part of the Application Services layer.
– Vladimir depicts an Onion Architecture with 3 layers: Core domain (Entities, Aggregates, Value Objects, Domain Events, Commands, Queries, Pure Domain Services), Non-core domain (Repositories, Impure Domain Services), Non-domain (Application Services, Command Handlers, UI).
– Commands follow the push model whereas Events follow the pull model.
– Commands and Data Transfer Objects (DTOs) are different things, they tackle different problems. Think in Commands as serializable method calls (calls in the domain model) whereas DTOs are data contracts between the API and its clients. This separation layer allows us to refactor or evolve the domain model without introducing breaking changes in the API (backward compatibility). We are used to doing this in our mapping between Entities and DTOs.
– Vladimir makes a really good point explaining that the reason why people often don’t see commands as part of the domain model is that in the controllers they skip the mapping stage and directly use commands for the request/response body. Don’t do that.
Continue reading “My notes on the video course “CQRS in Practice” by Vladimir Khorikov.”

Attending Jason Gorman’s TDD Workshop – 1/12/2018

Last weekend I had the pleasure to attend the TDD Workshop that Jason Gorman organises in London. Being myself a passionate TDD practitioner with years of experience I still found the workshop really interesting, having the opportunity to learn a few new things and reaffirm my ideas.

Sharing below my notes from the workshop:

– Demo 1 – Fibonacci Sequence.

– Classic mistakes of TDD
– Start with the production code.
– Test testing too many examples.

– Basic moves of TDD.
– One or two design decisions per test.
– Using it in the test is how you know you need it.
– Why is good/useful to see the test fail?
Mainly to have confidence going forward that the test will catch if someone breaks that code.
– The purpose of TDD is not to the test the code.
– TDD is about specification.

– Whenever you work, do baby steps, don’t stay in red for more than a few minutes. Go green as quick as you can.

– Looking at the history of a code base (using source control) can help to understand a legacy system.

– We have not finished yet because we can still think of more examples.
– Work backwards write assert first.
– Eclipse was design to do TDD to work in a backward way. Visual Studio is not like that.
– Kent Beck calls the Model Code vs Test Code.
– Having the class we are implementing in the same file that the tests breaks the SRP.
Continue reading “Attending Jason Gorman’s TDD Workshop – 1/12/2018”