The importance of setting the boundaries (of your domain models)

First article of the year! I really wanted to start writing this few weeks ago, but honestly I wasn’t inspired enough.
Now that I’ve spent a good portion of the Christmas break reading blogs, books and watching courses on Pluralsight, I still don’t feel inspired enough.

I guess it’s due to how I spent the other portion (eating, sleeping and playing with my kids, mostly), which left me basically without any energy at all.

But as they say, the first step is always the hardest, no?

Lately I’ve been putting some effort into improving my DDD techniques. For those of you who are still living under a rock, please consider taking a copy of the marvelous blue book by Eric Evans.

I still am in the middle of the learning process, even though I probably started this path years ago. Might be a sign of impostorism. Or it might be the fact that in this job, as in many other jobs, you never stop learning.

Not going to discuss about DDD now, or what the benefits are. I shall leave this for another post.

This is going to be just a very quick introduction about boundaries and aggregates instead. What’s an aggregate? An example should make things easier.

We can consider an Order our aggregate and Order Lines compose its internal state.

I said “internal” for a reason: the Order is the “entry-point”. We can’t have Order Lines without an Order that contains them and obviously an Order without Order Lines is pretty useless.

At the same time, you can’t access Order Lines from the outside world without going through the Order.

Clear? Definitely not rocket science.

Why “aggregate” ? Well, because you’re combining things together and building up a structure that mimics your current domain. The Order and the Order Lines are entities and value objects that will eventually form the Aggregate.

I’ll talk more about the distinction between Entities and Value Objects in another post, for now just take that for granted (or lookup on Google!).

For now just think that eventually your system will be a composition of multiple Aggregates acting and interacting together, and the quality of their interaction will be a representation of how good you know your Domain. Communication is the key here!

At this point I would say that the trick is to find the right balance and being able to identify the right boundaries for your Aggregates. Why? Simply because of divide-et-impera.

Our domain might be complex from the beginning, or become extremely complex over time. Everybody has seen this happening at some point. So take a deep breath, talk to your Domain Expert ™ and identify what are the edges and the sets of your entities. That’s it. Compartmentalize.

There’s a lot more to write on this, and I definitely will. When? That’s definitely a good question! A lot is going on in my life these days and weeks and I have the sensation that 2019 is going to be a crucial year for everyone here.

Ciao!

talk @ UniSa – 12/12/2018

Every couple of weeks or so the University of Salerno hosts former students like me to talk a bit about their professional experience. Yesterday was my turn!

I was invited by my old teacher Vittorio Scarano (hi prof!) to talk in front of a big audience of grads and undergrads. I had a lot of fun telling them my story, we discussed about my current Company, my daily job and routine and a little bit about Design Patterns (because, why not).

I got very interesting questions from them at the end and it’s amazing to see how much passion these young students have and how strong is their desire to learn and improve.

So a big, big thank you to everyone who attended! And just FYI:

  1. my team is always hiring, so make sure to check the latest open positions
  2. a very good friend of mine is hiring as well in Salerno, check it out!
  3. don’t forget to register to the DevDay Salerno community!

Testing the boundaries of your Web APIs

How do you make sure an entire software you wrote works? And how would you do that if your system doesn’t have a UI? Well, simply by testing the boundaries of course!

From time to time I like to extract pieces of code from what I’m working on and create small repos just to showcase a single functionality or idea. 

This time I’m putting some efforts on TDD on APIs and after few refactorings I came up with a nice structure that you can use as a starting skeleton for a simple system. You can find all the sources here on GitHub.

The demo is very simple, just a single controller that stores and provides user details. Nothing fancy. The user model class exposes only three properties: id, full name and email.

Few points worth noting though:

  • the class is immutable. I wrote a bit about the concept here.
  • I’m adopting the Special Case (or Null Object) pattern a lot these days. Hence the NullUser static property.

Persistence is done in-memory as it’s obviously outside the scope. Moreover, as you can see the Tests project contains only the end-to-end tests, no unit/integration test to cover the persistence layer.

The testing infrastructure is where things gets interesting, even though it’s actually fairly straightforward. An XUnit Fixture is firing up a TestServer and bootstrapping the application using (possibly) the same settings as the real system.

A shared WebHostBuilderFactory class is indeed responsible of building the required IWebHostBuilder instance.

That’s it!

Ok, just to be honest, I got the idea from Mark Seemann : he has a very interesting course on Pluralsight named “Outside-in TDD“. If you have the chance, I strongly suggest you to watch it.

So, now that we have our nice infrastructure ready, all we have to do is write our tests! Being this a Web API, these might be considered either “functional” or “end to end”.

Honestly I think it’s simply a naming thing and doesn’t change the fact that probably these should be the first tests you would write.

Why? Because (and Mark explains it really well in his course) you’re ensuring from the consumer’s perspective that your APIs do what they’re expected to do.

You’ll be “testing the boundaries”.

But most importantly, you’re validating your acceptance criteria and making sure your system works. 

Everything else is just an implementation detail.

So what are we testing here? The routes of course! Our API is managing users, and being it RESTful, we’re asserting that all the http verbs are doing what we expect to do. 

Most of these tests should derive directly from the acceptance criteria written by your Product Owner. In case you don’t have one but instead rely on some (even vague) specifications, a good starting point is simply testing inputs and outputs. 

Happy testing!

List of useful Docker commands

In the last few weeks I’ve been doing several experiments with Docker, just trying to grasp the main idea and maybe even come up with something useful.

As often happens with tools these days, there’s an entire world of command line tools that you should learn.

OR you can just be lazy as me and keep a list of the most common ones 🙂

I’ll be updating this list from time to time, just to keep track of what I’ve used so far and be a quick reference for my sloppy memory.

docker login [HOST] # in case you need auth to pull or push images
docker build -t [TAG]
docker images # shows a list of the local images along with the size
docker push [TAG]
docker rm $(docker ps -a -q) # this will remove ALL your containers. Be careful!
docker system prune -a # this will remove ALL your images and containers. Very useful when you run low on space, but be careful!

The next command will display the Docker daemon logs, extremely useful when you don’t know what happened (basically me most of the time) and you’re looking for an answer, even if obscure.

It depends on the OS you’re running on:

  • Ubuntu (old using upstart ) – /var/log/upstart/docker.log
  • Ubuntu (new using systemd ) – sudo journalctl -fu docker.service
  • Boot2Docker – /var/log/docker.log
  • Debian GNU/Linux – /var/log/daemon.log
  • CentOS – /var/log/daemon.log | grep docker
  • CoreOS – journalctl -u docker.service
  • Fedora – journalctl -u docker.service
  • Red Hat Enterprise Linux Server – /var/log/messages | grep docker
  • OpenSuSE – journalctl -u docker.service
  • OSX – ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/d‌​ocker.log
  • Windows – Get-EventLog -LogName Application -Source Docker -After (Get-Date).AddMinutes(-5) | Sort-Object Time, as mentioned here.

(thanks, Scott)

Immutable Builder Pattern

This time we’ll talk about the Immutable Builder Pattern, but with a twist: the resulting instance has to be immutable.

From time to time I need to move away from the routine, just to avoid getting bored. Also, taking short breaks might help viewing things under a different perspective. Anyways, while working on Statifier I felt the need to get back to the roots and dive a little bit into the Design Patterns World ™ .

Straight from Wikipedia:

“the intent of the Builder design pattern is to separate the construction of a complex object from its representation”

This pattern is indeed extremely useful when you have to create an instance of a complex class, eg. with a long list of properties that have to be initialized.

It can be confused sometimes with the Factory pattern, but there’s a very important difference: Factories can be used to create an object instance based on some rules and return an interface. The result will be any concrete implementation of that interface, but consumers won’t (and don’t need to ) know which one.

Builders instead know how to create a single, specific class and the result is exactly an instance of that class.

And why should I be using the Builder if it can create just one thing? Well maybe because the creation is complex and requires several steps. Maybe you cannot just do something like builder.Build(param1, param2…..) , but you need a more structured approach.

The Wikipedia page has already some good examples of how the pattern can be implemented so I won’t talk much about that. 

But what is immutability anyway? Why do I need it?

At its core, immutability is a simple, very important concept: don’t let anyone from the outside update the internal state of your objects. That’s it.

Coding-wise, it translates basically into classes with no setters at all. All the properties will be initialized in the cTor, along with all the dependencies.

And why should I use it? Here’s an excellent article by Martin Fowler (yeah I love quoting him). Take your time, I’ll wait.

Ok so now let’s get back to out Builder. Here’s a sample implementation:

Few points to note:

  1. Vehicle cTor is private. Only the Builder can create an instance, and this is the main reason why the Builder class is declare inside the Vehicle class.
  2. all properties on Vehicle are get-only. Internal state cannot be changed, immutability is ensured. Good luck changing them.
  3. every call to Build() creates a new instance of Vehicle. This is again made to ensure immutability but comes with a twist: you have to be more careful if you want to reuse an instance of the builder to create more vehicles. You’ve been warned.

© 2019 Davide Guida

Theme by Anders NorenUp ↑