Design by contract vs defensive data checking in Elixir?

Hello,

I have a question that is probably not limited only to Elixir, but I would like to have your opinion about ‘Elixir’-like, or ‘Elixir way’ solution to the question.

The problem I would like to discuss is the application of the ‘design by contract’ software design principle. In short, when designing a data exchange protocol, both sides of the interface agree on the data types and the boundaries of values used when calling the interface/protocol methods. And in the implementation the caller of the function ensures that the protocol is not violated.
I am coming from a world of languages like C++, Java, Python where design by contract is (at least in theory) applied quite often and to some degree supported by the compilers (C++/Java), Despite this fact, the actual implementations of the protocol are full of checks of the potential protocol violations to ensure that the program will not crash (a classical example is checking for the null value of variables passed as parameters to the method/function calls).

Although I am new to Elixir I feel that this problem can be solved quite elegant in many cases by clever application of proper data structures. But I am curious whether there are some best practices established in Elixir.

I have one concrete example illustrating the problem and the possible (as far as I can see) solutions:

1. The business logic of my application operates on the data structure representing a week. I encoded it as

defmodule WeeklyTimeDistribution do
  defstruct ~w[mo tu we th fr sa su]a
end

2. The business logic fills each entry of the WeeklyTimeDistribution with a struct, containing, between other the date of a specific day.

3. At the end of the processing I store the WeeklyTimeDistribution to external data storage via some boundary module. The module defines a protocol, that operates on the instance of the WeeklyTimeDistribution struct.

4. The API implementation takes days of the struct and tries to store them. Sometimes however, the storage is not allowed, so I need to exclude some days from storing (I know, it sounds a bit strange, but it is something I cannot change - without going into details: days of the week with dates in the future cannot be stored).

From this point I believe there are two choices:

1. Setup a ‘contract’ where I set the nil values for the days of the week not to be stored and implement the storage API to skip the days with ‘nil’ values from storing.
2. Change the data type used between the business logic and storage API by passing a map or a list of only valid days of the week (excluding the days in the future). So the contract says in this case: whatever I pass is “legal” and the boundary shall just store it without any checking.

The 2nd option looks more appealing to me because it makes the boundary (data storage module) simple (no checks for ‘nil’ prior to writing. The storage API just iterates over the passed data structure and stores the data.

Is there a common Elixir design pattern for this problem? Shall the boundary classes be just plain absorbers of the data? Or does some defensive programming still make sense in Elixir? What do you think?