DEV Community: lee eggebroten

Super simple validated structs in Elixir

lee eggebroten — Sat, 20 Apr 2024 17:31:42 +0000

In a prior article about a circle of trust, I discussed the substantial benefits of consistently using validated data structs as input parameters; Ecto.Changeset and Plug.Conn for example.

Even though there are clear benefits to this practice such as code that's easier to understand, easier to refactor, easier to test, with more useful feedback within IDEs, there can be resistance implementing it. Common pushback usually centers around the boilerplate "noise" of creating and maintaining the struct's "constructor" modules. That resistance is what motivated me to write the macro this article highlights.

This macro's goal is to extend TypedStruct with moderately powerful field-level defaulting and validation. The implementation imposes very little overhead (coding time or runtime), addresses the vast majority of use cases, and the created modules can be extended with your own functions for a very rich solution to data collection, validation, mutation, and parameter passing.

The Hex documentation provides a Livebook implementation to demonstrate using the macro and its benefits.

I am pleased to introduce you to the TypedStructCtor (where "ctor" is an abbreviation of constructor)

TypedStructCtor

TypedStructCtor is a TypedStruct plugin to add validating constructors to a TypedStruct module

The TypedStruct macro wraps field definitions to reduce boilerplate needed to define elixir structs and provides a plugin system enabling clients to extend the DSL.

TypedStructCtor uses the __changeset__ "reflection" function added by the plugin TypedStructEctoChangeset which enables Ecto.Changeset.cast on fields defined within the TypedStruct macro.

Try it out in Livebook

Try the macro out in real time without having to install or write any of your own code

To get started you need a running instance of Livebook

Rationale

Ecto.Changeset is a great way to create validated structs. However, if you've many validated structs they quickly become "noise", where writing these functions quickly become tedious, and bugs are easily introduced as struct changes are not easily overlooked.

When the effort needed to write boilerplate tests for boilerplate code is factored in, it can be tempting to skip struct validation altogether.

Simple Examples



    defmodule AStruct do
      use TypedStruct

      typedstruct do
        plugin(TypedStructEctoChangeset)
        plugin(TypedStructCtor)

        # A required field with a default value provided by MFA tuple to return a UUID
        field :id, :string, default_apply: {Ecto.UUID, :generate, []}

        # A required field with no default, meaning it must be provided to the constructor.
        # It's an `integer` with known `Ecto.cast` behavior, so for instance, string values are cast 
        # for example string to integer
        field :integer_field, :integer

        # An optional field with no default, meaning it will only have a value if provided to the 
        # constructor
        field :some_string, :string, required: false 
      end
    end

    iex()> AStruct.new(%{some_string: "foo"})
    {:error,
     #Ecto.Changeset<
       action: :new,
       changes: %{id: "36153915-bfd7-4067-85e1-03c9b0662582", some_string: "foo"},
       errors: [integer_field: {"can't be blank", [validation: :required]}],
       data: #AStruct<>,
       valid?: false
     >}

    # With `bang` notation and demonstrating Ecto's field cast (string to integer)
    iex()> AStruct.new!(%{some_string: "bar", integer_field: "42"})
    %AStruct{
      some_string: "bar",
      integer_field: 42,
      id: "2e28df41-c024-465e-901d-22c974f1d356"
    }

The TypedStruct macro makes it much easier to define structs. The TypedStructEctoChangeset plugin uses the field definitions to generate an Ecto.Changeset.cast function for fields in the struct. And this plugin, TypedStructCtor, uses those cast functions to generate validating constructors for the enclosing struct created by TypedStruct.

This plugin adds 5 constructors, new/0, new/1, new!/1, from/2, and from!/2 to the given module.

Ecto cast is called for all attributes provided to the constructors, defaults are applied where needed, and
validation is performed.

The new functions return {:ok, struct} or {:error, changeset}, while the new! functions return the struct, or raises if there were issues with cast or validation.

The new function takes an optional map of attributes, does Changeset.cast of all values matching the defined fields, adds defaults for fields missing values, validates any required fields, and finally calls Changeset.apply_action to validate the changeset. Returns {:ok, <struct>} if everything is OK, {:error, <changeset>} if there were issues with cast or validation. Because it's necessary to properly handle mappable fields, if a struct is passed to the new function, {:error, :attributes_must_be_a_map} is returned; use one of the from functions for that use case as described below.

The from functions are useful in messaging environments where a new message is created from a some set of values from a source message. They are similar to the new functions but accept a "base struct" as the first argument and a map of attributes as the second argument. The base struct is mapped first to the field values, and the attributes are merged on top.

Required Fields

By default, all fields are required when calling the constructors. Meaning you'll get a changeset error if the field does not have a default, and you don't provide an attribute value for it in the constructor.

You can override this by passing required: false to the plugin



  typedstruct do
    plugin(TypedStructEctoChangeset)
    plugin(TypedStructCtor, required: false)

    field :this_field_is_not_required, :string
  end

Or by passing required: false to the field definition.



  typedstruct do
    plugin(TypedStructEctoChangeset)
    plugin(TypedStructCtor)

    field :this_field_is_not_required, :string, required: false
  end

Field-level Defaults

default and default_apply can be provided to the field definition to specify a default value for the field.

Though you can specify both default and default_apply (an MFA tuple), only one will be used.

default will be used with Elixir's struct syntax (e.g. %AStruct{}).
default_apply will be invoked when one of the 5 constructor functions is used (e.g. AStruct.new!())

The default_apply function is short-circuited and will only be invoked if the given field was not present in the
attributes.



    defmodule AStructWithDefaulting do
      use TypedStruct

      typedstruct do
        plugin(TypedStructEctoChangeset)
        plugin(TypedStructCtor)

        field :field, :integer, default: 42, default_apply: {SomeModule, :some_function, ["55"]}
      end
    end

    iex()> %AStructWithDefaulting{}
    %AStructWithDefaulting{field: 42}

    iex()> AStructWithDefaulting.new!()
    %AStructWithDefaulting{field: 55}

Mappable Fields

As mentioned above, when using from and from! functions, the first argument is a "source" struct whose matching-name fields will be copied first into the struct being constructed. By default, all matching-name fields are copied, but the mappable? boolean attribute can be used to specify which fields are not copied. This is useful when you want the newly constructed struct to have different values for a field than the source struct such as created_at or id.

Not mapping over the source struct values will mean the newly constructed struct will leave the new fields empty unless defaulted or provided as attributes to the constructor.



    defmodule AStructWithMappableFields do
      use TypedStruct

      typedstruct do
        plugin(TypedStructEctoChangeset)
        plugin(TypedStructCtor)

        field(:id, :string, mappable?: false, default_apply: {Ecto.UUID, :generate, []})
        field(:created_at, :utc_datetime_usec, mappable?: false, default_apply: {DateTime, :utc_now, []})
        field(:reason, :string)
      end
    end

    # In the example below, the `id` and `created_at` fields are `mappable?: false` so they are not 
    # copied from the source struct.  So in the new struct, `:reason` is copied from the source 
    # struct, `:id` is provided in the attributes map, and `:created_at`, being nil after all the
    # copying is done, causes its default to be used instead, resulting in a new date.
    iex()> source_struct = AStructWithMappableFields.new!(%{reason: "because"})
    %AStructWithMappableFields{
      reason: "because",
      created_at: ~U[2023-11-18 04:57:16.754681Z],
      id: "ffe94776-5d6e-4d84-9aeb-2862d874577f"
    }

    iex()>  Process.sleep(5)
    iex()>  mapped = AStructWithMappableFields.from!(source_struct, %{id: "id from attributes"})
    %AStructWithMappableFields{
      reason: "because",
      created_at: ~U[2023-11-18 04:57:16.766353Z],
      id: "id from attributes"
    }

    iex()> Process.sleep(5)
    iex()> mapped = AStructWithMappableFields.from!(source_struct, %{reason: "I said so"})
    %AStructWithMappableFields{
      reason: "I said so",
      created_at: ~U[2023-11-18 04:57:16.772312Z],
      id: "a09be86b-373a-48f0-9d74-faee10037421"
    }

Installation

Because this plugin supports the interface defined by the TypedStruct macro, installation assumes you've already added that dependency.

While you can use the original typed_struct library, it seems to no longer be maintained. However, there is a fork here that is quite active.

The package can be installed by adding typed_struct_ctor to your list of dependencies in mix.exs:



def deps do
  [
    # Choose either of the following `TypedStruct` libraries 
    # both use the same name for the macro - `typedstruct` but
    # but are mutually exclusive:

    # The original, but no longer maintained library
    {:typed_struct, "~> 0.3.0"},

    # Or the newer forked library
    {:typedstruct, "~> 0.5.2"},

    # And add this library  
    {:typed_struct_ctor, "~> 0.1.0"}
  ]
end

You need a Circle of Trust for faster and safer development

lee eggebroten — Tue, 26 Mar 2024 19:56:57 +0000

Do you want faster development, less code, fewer tests, higher quality code, fewer production failures, and a better customer experience all at nearly no additional development cost? Consider building a Circle of Trust.

One of the fantastic principles enabled by Elixir is the freedom to “let it crash”. We all recognize that it’s impossible to write perfect, failure-free code. And even if we could somehow, hardware failures and even radiation can still corrupt your state, creating situations you simply cannot recover from. So … let the process and its bad state die, and start over from a clean slate. Simple. Beautiful.

Sadly though, most failures we encounter are of our own making. Either our algorithms introduced the bug, or more likely, we didn’t account for certain state. That uncertainty of state invariably leads to overly defensive and hard-to-follow code, and frequent production failures that are difficult to debug. Which is only made worse when using Elixir’s super-efficient processes to improve performance because the logged stack traces can be nearly useless trying to locate the error source. “Awesome … an anonymous in-lined Erlang function inside a GenServer callback. Good luck finding that one!”.

While test suites run during build/deploy to prove that anticipated problems are handled somewhere in our code, a Circle of Trust is a runtime concept like a Customs officer; always checking that the provided goods are in fact what we were told to expect. That way, if we’re given bad state from an outside source it’ll never reach our algorithms, and a full report can be created to make it easier to find the offender. And, like the Customs officer, you have only one place to go to define what is permitted, how sources should be packaged, and what is available in the shipment.

A Circle of Trust has almost no real development cost. It’s easy to start, provides immediate rewards, and dividends increase the more you invest. Stay with me, I’ll clarify some of the substantial benefits below once I’ve explained what it is.

So … what IS a Circle of Trust?

A Circle of Trust adapts the OO engineering principles of Encapsulation, and Separation of Concerns into Functional Programming using modules to validate data that originated outside your control and provide accessors for that data. This allows internal algorithms a level of trust for source data and a measure of isolation from structural changes source data may experience later. Once the module is created, move all defensive “what about this” code into that module’s validation routine.

That’s it.

Granted, some of the benefits of a Circle of Trust can be realized by more traditional functional or interface test suites. But unless your system has super high performance requirements, the run time validation in a Circle of Trust can provide far more bang for your buck. And, if some validations do create bottlenecks, the costly portions can be moved to your interface test suite.

Author’s side note: I would be surprised if you found a formal software related definition for “Circle of Trust”. It is a term our Atlas team at aQuantive started using to refer to the concept of runtime validation and encapsulation of source data. Even though we had substantial unit and interface test suites, adopting this principle provided all the benefits described here.

Let’s have an example applied to incoming data from a simple “Contact Us” form a customer might use to inquire about something. To shorten things up a bit I’ve left off most @spec and @doc attributes.

Here I’ll use Ecto to validate that required fields were present and mutate data types where needed, provide declarative valid?, if data is invalid errors clearly identifies what was wrong, and finally it provides accessors to those fields either as a collection from fields or individually such as email.

defmodule Email.Schema.ContactUs do
  use Ecto.Schema
  import Ecto.Changeset
  alias Email.Schema.ContactUs

  embedded_schema do
    field(:email, :string)
    field(:subject, :string)
    field(:message, :string)
    field(:request_date, :date)
  end

  @type t :: %__MODULE__{
          email: String.t(),
          subject: String.t(),
          message: String.t(),
          request_date: Date.t()
        }

  @valid_subjects [
    "General Question",
    "Order Status",
    "Compliment",
    "Complaint",
    "Other"
  ]

  def cast(form_data) do
    %ContactUs{}
    |> cast(form_data, ~w(email subject message request_date)a)
    |> validate_required(~w(email subject message)a)
    |> validate_format(:email, ~r/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/i)
    |> validate_inclusion(:subject, @valid_subjects)
  end

  def valid?(%Ecto.Changeset{valid?: valid}), do: valid
  def errors(%Ecto.Changeset{errors: errors}), do: errors

  def fields(%Ecto.Changeset{changes: changes}), do: struct!(__MODULE__, changes)

  def email(%Ecto.Changeset{changes: %{email: email}}), do: email
  def subject(%Ecto.Changeset{changes: %{subject: subject}}), do: subject
  def message(%Ecto.Changeset{changes: %{message: message}}), do: message
  def request_date(%Ecto.Changeset{changes: %{request_date: request_date}}), do: request_date
end

Its unit test file clarifies expectations from validation and accessors.

defmodule Email.Schema.ContactUsTest do
  use ExUnit.Case

  alias Email.Schema.ContactUs

  describe "cast/1 when all data is valid" do
    setup [:valid_data, :execute]

    test "valid? returns true", %{data: _data, results: results} do
      assert ContactUs.valid?(results)
    end

    test "email matches source data", %{data: data, results: results} do
      assert ContactUs.email(results) == data.email
    end

    test "subject matches source data", %{data: data, results: results} do
      assert ContactUs.subject(results) == data.subject
    end

    test "message matches source data", %{data: data, results: results} do
      assert ContactUs.message(results) == data.message
    end

    test "request_date is converted to Date type", %{data: _data, results: results} do
      assert ContactUs.request_date(results) === ~D[2019-10-28]
    end

    test "fields returns expected struct", %{data: data, results: results} do
      fields_is_as_expected(data, results)
    end
  end

  describe "cast/1 when missing required fields" do
    setup [:missing_data, :execute]

    test "valid? returns false", %{data: _data, results: results} do
      assert ContactUs.valid?(results) == false
    end

    test "reports missing required fields", %{data: _data, results: results} do
      assert ContactUs.errors(results) == [
               email: {"can't be blank", [validation: :required]},
               subject: {"can't be blank", [validation: :required]},
               message: {"can't be blank", [validation: :required]}
             ]
    end

    test "fields returns expected struct", %{data: data, results: results} do
      fields_is_as_expected(data, results, nil)
    end
  end

  describe "cast/1 when invalid subject" do
    setup [:valid_data, :invalid_subject, :execute]

    test "valid? returns false", %{data: _data, results: results} do
      assert ContactUs.valid?(results) == false
    end

    test "reports missing required fields", %{data: _data, results: results} do
      assert ContactUs.errors(results) == [
               subject:
                 {"is invalid",
                  [
                    validation: :inclusion,
                    enum: ["General Question", "Order Status", "Compliment", "Complaint", "Other"]
                  ]}
             ]
    end

    test "fields returns expected struct", %{data: data, results: results} do
      fields_is_as_expected(data, results)
    end
  end

  describe "cast/1 when invalid request_date" do
    setup [:valid_data, :invalid_request_date, :execute]

    test "valid? returns false", %{data: _data, results: results} do
      assert ContactUs.valid?(results) == false
    end

    test "reports missing required fields", %{data: _data, results: results} do
      assert ContactUs.errors(results) == [
               request_date: {"is invalid", [type: :date, validation: :cast]}
             ]
    end

    test "fields returns expected struct", %{data: data, results: results} do
      fields_is_as_expected(data, results, nil)
    end
  end

  defp fields_is_as_expected(data, results, expected_date \\ ~D[2019-10-28]) do
    expected = %Email.Schema.ContactUs{
      email: data[:email],
      message: data[:message],
      request_date: expected_date,
      subject: data[:subject]
    }

    assert expected == ContactUs.fields(results)
  end

  defp valid_data(_context) do
    data = %{
      email: "foo@bar.com",
      subject: "Compliment",
      message: "message",
      request_date: "2019-10-28"
    }

    {:ok, data: data}
  end

  defp missing_data(_context) do
    {:ok, data: %{}}
  end

  defp invalid_subject(%{data: data}) do
    {:ok, data: put_in(data, [:subject], "this subject is not in approved list")}
  end

  defp invalid_request_date(%{data: data}) do
    {:ok, data: put_in(data, [:request_date], "10-28-2019")}
  end

  defp execute(%{data: data}), do: {:ok, results: ContactUs.cast(data)}
end

And now an example of how we might use it.

Given the form data from the customer’s request, use the ContactUs.cast function to fully validate the data. If data from the form is not valid? we can use errors to clearly inform the user what was wrong (or perhaps log if source data is from an external API). If state is OK, we can use accessors (like ContactUs.email(contact_data)) to obtain form data without worrying about where it is or about possible future minor structural changes.

defmodule Email do
  @moduledoc """
  Sends emails from our `Contact Us` form.
  """
  alias Email.{Mailer, View}
  alias Email.Schema.ContactUs
  import Bamboo.Email

  @doc """
  Generates and sends an email from a contact_us form submission.
  """
  def send_contact_us_email(contact_us_attrs) do
    contact_us_attrs
    |> ContactUs.cast()
    |> case do
      %{valid?: true} = contact_data ->
        contact_data
        |> contact_us_email()
        |> Mailer.deliver_now()

        {:ok, contact_data}

      %{errors: errors} ->
        {:error, errors}
    end
  end

  @doc false
  def contact_us_email(%ContactUs{} = contact_data) do
    new_email()
    |> to("customerservice@my_company.com")
    |> from("contact-form@email.my_company.com")
    |> put_header("Reply-To", ContactUs.email(contact_data))
    |> subject(ContactUs.subject(contact_data))
    |> render("contact_us_email.html")
  end

  defp render(_data, _template), do: "left as an exercise for the reader"
end

Finally, let’s explore some ways a Circle of Trust can lend a hand.

Failures happen. Support Agile’s Fail Fast principle
Ensures contracts. We’re all working together. That’s both good and bad. It can be difficult keeping a growing number of developers in synch. You’ll identify problems with production pushes/rollouts sooner.
Enables better error messaging for known-bad conditions. “Hey, we aren’t supposed to be getting a nil image URL and we got one”. We can log something sane rather than a huge pattern match failure somewhere inside of an anonymous callback with no idea where the call originated from.
Having context and source data provides the opportunity for better customer feedback on failure rather than “oops, something went wrong”.
Makes testing easier. Because you know that certain data states can never happen, you don’t have test for those cases.
Makes testing easier #2. Data-modules can help create more resilient tests. By abstracting data state to these modules, the tests can be shielded from change when underlying data formats change.
Reduces production code. Because you can filter out invalid data-states, you don’t have to write code to handle them.
Coding is faster and safer. The declarative nature of these data modules makes writing both production and test code much faster and safer.
Refactoring is easier. It should be obvious that it’s simpler to update and test an accessor than to find all client code directly accessing source data. “Their API just changed id to user_id" … yeah, that’ll be a fun grep and Code Review.”
Shared business logic. These modules provide a convenient place for common code. For instance, rather than having date format logic sprinkled everywhere in your code, do it here.
When combined with Application Layering, you’ll have an appropriate place to provide “living” documentation about your architecture, and its expectations.
YAGNI and KISS. We should avoid over-engineered and unneeded “what if” investments in our code. And sometimes the best way to reduce code complexity is to do a better job of domain modeling. However, it is quite rare that you’ll fully understand your data domain right away. A Circle of Trust makes it far easier to make these additions later when things are clearer.

There are many paths to good code. I hope you can see that adding a Circle of Trust allows for faster development, less code, fewer tests, higher quality code, fewer failures, and more helpful error messages. All at the negligible cost of writing a module that encapsulates the data parsing and validation you’re already doing.

Feature Guides enable the best of "Full Stack" and domain expertise

lee eggebroten — Tue, 26 Mar 2024 15:05:39 +0000

Want more dependable feature delivery, happier developers, increased velocity and performance, all at a lower overall cost? Consider horizontally aligned teams utilizing Feature Guides.

When it comes to software development there really are only two ways to organize your team; Full Stack (vertically aligned feature teams), or domain based (no, not heap).

Full Stack

Jack of all trades and (usually) master of none

Vertically aligned development, is seductive. In theory, it puts into the hands of the Product Manager, direct control of all the developer resources needed to complete tasks throughout the company's technical domains. These might include: UI, middleware, server, database, distribution, monitoring, and DevOps.

Thus, theory goes, this full access to the means of production guarantees quality products, on time, on budget, with an ever increasing velocity. And, for a short time this is true. With clear, focused, business objectives its easy to prioritize a team's skills and resources to achieve goals. Unfortunately, it fails for one simple reason; humans.

Mastering all the skill proficiency requirements for Full Stack is more than can be expected of any but a handful. Consider this non-inclusive list of some of the languages, libraries, and frameworks a developer would need proficiency with (not just familiarity) to be truly "Full Stack";

CSS
HTML
Slime/transpilers
Javascript
Ajax
JQuery/Selectors
Bootstrap
Underscore
Angular/Phoenix/React/Rails
REST
GraphQL
Redis
MySql/Postgres
Kafka/RabbitMQ
Phoenix/Phoenix Live
Elixir/Ruby/C#
plus all associated test frameworks.

That's a lot to learn, but mastering something requires far more than mere proficiency with its syntax.

Like any natural human language, each software language, library, and framework has its own idioms, dialects, and phraseology that can take varying degrees of time to master. And, like natural language, lacking that fluency usually produces poor, and sometimes disastrous end results. Also, software languages, tools, frameworks, and paradigms evolve rapidly, requiring constant attention to maintain fluency.

But wait, it gets worse

Each domain of a product's technical stack has considerations beyond the language chosen to implement it. For instance, adding a column to a database is a simple thing. But the consequences of doing it in the wrong place can have large impacts on your business that are difficult to unravel. Additionally, proper testing techniques for all those languages can vary substantially and doing it wrong can hide failures, and even hamstring new features in production code.

Granted, some of these negatives can be countered with skill sharing and consistent, high quality code reviews. But again, this kind of diligence is difficult to achieve in the long term when deadlines rear their ugly heads.

According to LinkedIn, the turnover rate for software developers is the highest of any sector at over 13%. How much knowledge sharing, code consistency, architectural direction, and quality will be quantitatively passed along when average tenure for all but the highest paying companies is about 2 years?

You mean we gotta pay them too?

It probably goes without saying, but with the greater number of fluency requirements, the harder it will be to find and evaluate qualified employees. Correspondingly, their pay expectations will be higher, and the more likely they'll be hired away.

That's bad, what do you propose?

Domain (horizontal) alignment

Generally speaking horizontal development is organized around domain competencies, and the extended experience needed to make wise decisions for the long term health of the code base.

UI, for instance, needs language skills specific to their target devices (desktop, iOS, Android), and browsers. This domain also requires a unique set of experience-based skills on how to make the customer interface responsive, reliable, and efficient. Due to all the devices and browsers, potential corner cases are plentiful and only experience can avoid them. Given that your UI is usually the first contact your customer has with your product, the need for experience in this domain is obvious.

"Platform" or "server side" code has similar domain specific concerns. Mistakes here are easy to make, expensive to fix, and can have a deep and potentially fatal effect on the product. Experience in this domain helps companies anticipate and design for concurrency demands, response times, memory requirements, reliability, architectural separation, and scaling.

Benefits of domain alignment

Given this, there are several benefits horizontally aligned organizations have over those that are vertically aligned. Generally these benefits are due to reduced breadth of proficiency requirements, increased depth in those proficiencies, and more applied long-term experience. Some examples:

Easier to find (and evaluate) qualified, like-minded employees.
Greater focus on domain concerns, yields higher quality of code
Higher code quality enables increased velocity and improved customer value and reliability
Better appreciation of domain specific architectural issues decreases likelihood of introducing costly design flaws.

One subtle benefit that shouldn't be overlooked is the human component. While Full Stack development frequently suffers from Tragedy of the Commons, the more localized code base of horizontal organizations benefit from pride of ownership.

Simply put, it's much easier to fully understand your domain and become beneficially invested to make "your" code base better.

So why isn't everybody horizontally aligned?

Using traditional business processes, it can be difficult to predictably provide customer value when you have to drive requirements down through all those layers. Each layer has its own domain-specific concerns, deadlines, and delivery requirements. This is usually complicated by conflicting priorities and schedules of internal customers.

So, how do you get the predictable delivery benefits of Full Stack and the performance, reliability, and long-term velocity benefits of horizontal?

You need Feature Guides of course

Create a development-focused role mirroring the Product Manager's Business focus. This person needs to work closely with the Product Manager to understand the business needs, assist them in clarifying missing technical aspects, work with domain-teams to identify any long or short term impacts on architecture, ensure any needed preliminary designs or prototypes are created, solicit input on broad-based implementation strategies and any architectural changes, coordinate with domain teams to appropriately prioritize work within their schedules, and finally track the progress, quality and completeness of the required work.

In some organizations these responsibilities might fall to the Development Manager, but personal experience shows much greater benefit for the organization if it's delegated to the developers themselves. Such as:

The Human element of "owning" features is a powerful motivator
Identifies developers ready for more responsibility
Provides a "safer" way for developers to "try their hand" in different domains and languages they might have interest in
Opportunity to groom and assess likely leadership candidates; which are always in short supply
Builds a more thorough understanding of the overall architecture
Cross-team coordination improves ties within the whole development organization
Attributable ownership leads to greater opportunity for recognition and improved morale
Project success rates provide more quantifiable metrics for performance evaluation
Greater breadth of interactions improves the quality of peer reviews

It should be obvious that the seniority of the Feature Guide would be relative to the breadth and corporate impact of the feature. The Guide's primary responsibility is not necessarily do all (if any) of the work themselves but rather to coordinate and facilitate the technical details of predictably releasing high quality customer value.

Nothing is black and white

When a company or product is in its infancy, the smaller teams, reduced domain responsibilities, and need for an immediate marketable product (whatever the cost), then Full Stack can provide that focus.

However, the when the company first feels the unwieldy nature of all the accumulated tech debt and talks begin of the first re-write, they should switch to Horizontal and Feature Guides or it's likely the "new thing" is going to look just like the "old thing".