DEV Community: Callum Lamont

An Initiation to Domain-Driven Design

Callum Lamont — Mon, 13 Jan 2025 04:19:34 +0000

What is Domain-Driven Design (DDD)? I used to group it with the other programming acronyms (TDD, SOLID, KISS, YAGNI, DRY, etc.). Maybe something developers should practice, but often don’t. That changed after I read Vaughn Vernon's book Implementing Domain Driven Design.

As developers, we are told what constitutes "good code". There should be high cohesion, low coupling, single responsibilities, information hiding, and so on. But these ideas are abstract. While the benefits of these characteristics are clear, it’s not always obvious how to achieve them. Well, DDD is one way. It describes a number of patterns that will help you write clearer, less coupled, extensible, cohesive code that aligns strongly with the business' goals.

A core tenet is that your code should model the domain you are building a solution for. If a business process change is conceptually simple, so is the required code change. No more explaining to a product manager why a basic feature request will actually take weeks to implement. I am relatively new to this methodology. So I won't provide a more detailed description than that. Instead, I will share some useful DDD patterns I've come across. These are good general programming practices. You don't need to "do" DDD to follow these. But if you think they are insightful, I would encourage you to check out the resources listed at the end.

Some useful DDD patterns:

Understand what you're building, and why.
Understand your relationship with other services.
Understand the type of object you’re creating.
Use immutable Value Objects.
Use rich domain models.
Hide your domain models from the outside world.

Understand what you’re building, and why

Don’t make assumptions about what you’re building. Discuss and explore it with the domain expert. This could be your product manager or clients. Through this collaboration, both the technical and non-technical team members will better understand their business, user needs, and value they are delivering. The process of exploration may even help the domain experts uncover areas of uncertainty. Plan and design. Do not immediately jump into coding.

Part of this process involves the creation of a Ubiquitous Language, a shared language describing the domain. A common approach for this modelling process is Event Storming. The Ubiquitous Language is used by both domain experts and within the codebase. As Vaughn Vernon writes in Implementing Domain-Driven Design:

We should build software that is as close as possible to what the business leaders and experts would create if they were the coders… There are zero translations between the domain experts, the software developers, and the software.

Imagine an application for booking tickets at a cinema. What's a good name for a function that saves the finalised booking in the backend? Should the method be createBooking or confirmBooking? The word "create" leaks developer knowledge into the codebase. They know a new record is being created in the database. And, ultimately, that is what this function does. But the name confirmBooking better describes the real life use case. "Create" is not the verb a customer would associate with the confirmation step of the booking process.

Understand your relationship with other services

Before designing a service, take a moment to understand how it fits into your wider technology ecosystem. Some services exist to support unrelated parts of the business. And there are services that your new service will need to interact with. Understanding this space is called Context Mapping. You might incidentally do this when designing a new system. However, for DDD it is an explicit process. It goes so far as to characterise the relationships underpinning these services. Below are a few examples. Check out more at this useful repository.

Partnership

The upstream and downstream teams succeed or fail together. Models and interfaces are developed to suit both their needs and any features and planned between them to minimise harm.

Customer-Supplier Development

The success of the upstream team (the supplier) is independent of the downstream team. But they take the downstream's needs into account when planning.

Conformist

The upstream team does not accommodate the downstream team’s needs. The downstream team conforms to the models of the upstream team, whatever they are or change to.

A lot of confusion and frustration might be avoided if these relationships are agreed between participating teams ahead of time.

Understand the type of object you’re creating

In object-oriented programming (OOP), our codebases are full of classes. These are often loosely categorised into vague concepts like services and repositories. However, these categories and their definitions vary from one project (or developer) to the next. So in each new codebase, we spend time understanding the responsibilities of each class.

Without formal definitions, it is easy for the scope of these classes to grow. And then the level of abstraction becomes lost. Fortunately, DDD provides concrete definitions for model categories, and rules for how they can interact. The vocabulary is simple, yet empowering. When you don’t have to define the building blocks of your application, you can focus more on what you’re building. These are the “tactical patterns” of DDD. Some examples are:

Value Objects

Immutable objects that represent a value with no identity. These can be replaced, but cannot change, over time. Two Value Objects are considered equal if they hold the same values (i.e. structural equality).

Entities

Objects that have a unique identity. Two Entities with the same identifier are considered equal, even if all other properties are different in value. These represent concepts in your domain that you need to observe and track changes to over time.

Aggregates

These are a grouping of Entities and Value Objects that represent a consistency boundary. If there is some invariant or business rule that must be maintained when updating a group of objects (and rolled back everywhere upon failure), then they belong together in an Aggregate. One Entity will serve as the Aggregate Root, through which all behaviour is orchestrated.

What if another Entity is changed at the same time as the Aggregate? If there is no requirement to maintain consistency between the two objects (and really challenge yourself on this point!) then it shouldn't be part of the Aggregate. Instead, it can be updated through an event-driven process that is eventually consistent. The goal is to make each Aggregate as lightweight as possible.

Domain Services

A Domain Service helps realise business logic and coordinates actions between your domain models (i.e. Aggregates). Importantly, only use Domain Services when the behaviour being orchestrated cannot logically belong to a single Aggregate (see below).

Application Services

These allow your domain logic to interface with the external world (API, persistence stores, etc). No business logic belongs here. Each method represents a single business use case. And each method achieves its goal by interacting with the Aggregates and Domain Services.

Use immutable Value Objects

Try using Value Objects wherever possible. Replacing both primitives and classes with Value Objects will make your code more self-documenting, easier to maintain, and less prone to bugs.

Let us consider a Kotlin application for booking tickets at a cinema. Perhaps it was first written like below.

class TicketDetail(
    var ticketType: TicketType,
    var filmId: UUID,
    var sessionTime: LocalDateTime,
    var seatTheatre: Int,
    var seatRow: Char,
    var seatNumber: Int,
    var price: BigDecimal,
    var discount: BigDecimal,
)

fun confirmBooking(
    customerId: UUID,
    cinemaId: UUID,
    ticketDetails: List<TicketDetail>,
) {
    // Business logic...
}

We can improve this by introducing Value Objects. Value Objects are immutable, so we replace all use of var with val. And we use data class to enable structural equality when comparing objects. The same can be achieved by record classes in Java and data classes in Python.

data class CustomerIdentifier(val value: UUID)
data class CinemaIdentifier(val value: UUID)
data class FilmIdentifier(val value: UUID)

data class Seat(
    val theatre: Int,
    val row: Char,
    val number: Int,
)

data class TicketPrice(
    val price: BigDecimal,
    val discount: BigDecimal,
) {
    // Validates that discount < price
}

 data class TicketDetail(
    val ticketType: TicketType,
    val seat: Seat,
    val price: TicketPrice,
) {
}

data class BookingDetails(
    val customerId: CustomerIdentifier,
    val cinemaId: CinemaIdentifier,
    val filmId: FilmIdentifier,
    val sessionTime: LocalDateTime,
    val ticketDetails: List<TicketDetail>,
) {
    // Validates at least one seat being booked
    // Validates all seats positions are unique
}

fun confirmBooking(
    details: BookingDetails,
) {
    // Business logic...
}

These changes introduce a number of benefits.

Improved readability

Each type actually means something in our domain. They are not primitives. Also, related concepts can be grouped together. For example, all aspects of the seating location (theatre, row, seat number) are grouped into the Seat class. This improves readability and reduces the number of method parameters.

Better type safety

Now it’s harder to accidentally swap the order of the method parameters that previously had the same type (i.e. UUID). For static languages, the compiler will complain if the values for customerId and cinemeaId are swapped. For dynamic programming languages, such errors can now be caught by the linter (if you use one).

Improved evolvability.

What if we want to change the data type representing an identifier (e.g. change the cinema identifier to Int )? Previously, we would need to update all class and function definitions using that identifier. Now we only need to update a few lines in the CinemaIdentifier class.

Validation

Basic data validation is included in the Value Object construction. This is much better than scattering around (and possibly repeating) validation in the methods the data is used. It improves reliability, because the data is guaranteed to be validated. And it improves readability, as the business logic can now focus on the use case.

Immutability

Value Objects are immutable. Once one is instantiated and validated, you know it is valid, always. Because Value Objects are immutable, any methods are side-effect free. Value Objects can be passed around a multi-threaded application with confidence.

Use rich domain models

Don't compose your application with only weak (or anaemic) domain models. These are classes that hold data but don't include any business logic. The result is that all logic is pushed into what developers often label "services" (but these are different to the DDD definition of Services provided above).

For an application with anaemic domain models, a developer might write a class like below to perform the business logic.

class BookingService {

    fun confirmBooking(details: BookingDetails) {
        // Business logic...
    }

    fun updateBooking(bookingId: BookingIdentifier, updatedDetails: BookingDetails) {
        // Business logic...
    }

    fun cancelBooking(bookingId: BookingIdentifier) {
        // Business logic...
    }

}

What's wrong with this? Well, the term "booking service" is pretty vague. It currently handles the logic for the creation, modification, and cancellation of a single booking. But should it include logic for listing historical bookings made by a customer? Or searching for a particular booking? Hmm, maybe, but possibly not... Regardless, if a product manager requests this functionality, I bet the logic will be added to this class. And through this process the class grows in scope and loses cohesion. And each new functionality will require more injected dependencies. Over time this scope creep creates God Classes.

What is the alternative? In DDD domain models aren't necessarily simple data holders. They represent a core concept in your domain. Thus, they should not only hold the data, but also the behaviours that involve that data. These are called rich domain models.

In the previous section I treated the BookingDetails as a Value Object. But if we put our DDD hats on, we can see a booking is actually better modelled as an Entity. That's because each booking is unique. It is a thing that can be updated over its life. Thus we need to track it with a unique identifier. With some minor adjustments, we can improve our booking service from before.


 data class TicketDetail(
    val ticketType: TicketType,
    val seat: Seat,
    val price: TicketPrice,
) {
    fun withNewSeat(newSeat: Seat) {
        return new TicketDetail(ticketType, newSeat, price)
    }
}

class Booking(
    val bookingId: BookingIdentifier = BookingIdentifier.new(),
    val customerId: CustomerIdentifier,
    val cinemaId: CinemaIdentifier,
    val filmId: FilmIdentifier,
    var sessionTime: LocalDateTime,
    var ticketDetails: List<TicketDetail>,
) {

    fun changeSeats(newSeats: List<Seat>) {
        ticketDetails = ticketDetails.zip(newSeats).forEach {ticket, seat ->
            ticket.withNewSeat(seat)
        }
    }

    fun cancelBooking() {
        // Business logic...
    }

}

Our booking class clearly represents a single booking, and actions associated with it. It is unlikely a future developer would bastardise this class by adding methods like getAllBookings or findBooking. Thus, we have better preserved the cohesion of our codebase going into the future. And maximising the maintainability of a codebase is critical for any long-lived application. There is no longer a "create" function, as this is simply performed through the act of instantiating the class. And the actions that can be made on this Entity are clearly defined by the class methods. Instead of the vague updateBooking method, we have changeSeats. The code reflects the actual use case and tells the developer why it's there.

Hide your domain models from the outside world

All projects have dependencies for communicating with the outside world. These could help serve RESTful endpoints, communicate with other services via RPC, or connect to a database. While necessary, none of this has anything to do with the purpose of the service. So, there is no reason to couple these external dependencies to any core business logic. This principle is often referred to as clean architecture. DDD is not the only proponent of this style. But, with its strong emphasis on considered domain models, it does scream out for such an approach.

Any layered architecture can achieve the separation of concerns required for clean architecture. My favourite is the Ports and Adapters (i.e. Hexagonal) style. It strongly promotes the use of clean domain models. The "ports" surround your core logic and serve as points of entry to your application. These ports are typically defined as interfaces. The concrete implementations of these interfaces are the "adapters" that leverage libraries and other dependencies to serve their function.

An illustration of the Ports and Adapters architecture, where arrows point in the direction of dependency. If needed, we can easily change our datastore from PostgreSQL to MongoDB. Inbound and outbound ports don't only interface with APIs and databases. This is only an example.

What's wrong with a simple three-layer architecture, with a presentation, application, and data-access layer? If done well, nothing. But, particularly if combined with an object-relational mapping (ORM) framework, it can enable developers to take shortcuts. These reduce the maintainability of the project over its life. For example, with the ORM classes it is possible for the presentation layer to directly interact with the database. And a lazy developer might choose to do this for a simple CRUD operation, instead of passing data unnecessarily through the application layer. Over time, such a shortcut might occur for another reason. And then again, and again. The result is logic spread over all the layers of your application, defeating the original purpose of the layered architecture.

Further, ORMs promote database driven design. It's easier to pretend your ORM classes are the core models of your application. But that means your "model" actually reflects how the data is organised in the database, not how it's represented in real life. And if these ORM classes are used as your core "models", then good luck ever switching frameworks down the line. The ORM dependency is now tightly coupled to all your logic. You will effectively need to re-write your entire application. I have also seen the same mistake occur for gRPC generated data access classes. Best use a clean architecture and leave these dependencies out of your core business logic 😌

A Simple Guide for Choosing the Right Database

Callum Lamont — Sun, 05 Jan 2025 21:47:20 +0000

Why would you pick PostgreSQL to support your next application when you have dozens of alternatives to choose from?

Databases are a tool to be leveraged by your application. But you should select the right tool for the job. You wouldn’t stubbornly use a hammer for every DIY project because you already know how a hammer works.

So which database should you use? Of course, this is influenced by many factors. But above all, ask what type of data model aligns with your application. Why? Because this is a strong indicator for how efficiently a database can organise and retrieve your data. Other technical and practical reasons can then be considered in your final technology choice.

If you would like to learn more after reading this piece I would strongly recommend Designing Data-Intensive Applications by Martin Kleppmann. I reference other useful resources at the end of the article for the eager.

What is a data model?

A data model describes how data is structured and logically organised in a database. For example, SQL databases typically use a relational model, where relations are stored in separate tables. The data in these tables are then stored physically separate on disk. Clearly this impacts how reads and writes are performed, and may not be ideal for your application. Other data models include document, wide-column and graph models. In certain use cases, it is also possible to effectively ignore the data model altogether!

Data models are not interchangeable. Each makes assumptions about how the data is structured and will be accessed. A mismatch between the data model of your database and your application will impact performance. So, when building a new application, ask yourself these questions:

Will the written data adhere to a strict schema?
Will the data have many-to-many relations?
Is it useful to retrieve or update only part of the data? Or will you read and write it in full?

We will see how the answers to these questions can help you identify the right data model and database.

No data model (i.e. key-value stores)

Example databases: Riak, RocksDB

Key-value stores offer the simplest approach to modelling data. Data exists, and is referenced by a unique key. That is pretty much it. Not all key-value stores are quite that ambivalent. Some offer slightly more query support for certain data types. But, as an oversimplification, there is no data model.

RocksDB is an extreme example of this strategy. It is a key-value store where both the key and values are arbitrary byte arrays. These are stored together in an index. The database makes no assumptions what is being stored, how it is structured, and how it might be queried. Conceptually, stored records would look like this:

RocksDB stores key-value pairs together in an LSM tree index. Other key-value stores may store data differently.

This design benefits write throughput. There is only a primary index, which typically uses an LSM tree. To generalise, this append only data structure should write faster than the commonly used B-tree index. Further, the database doesn’t need to update secondary indexes on writes. It doesn’t even validate constraints or data formatting for the written value. Making the data in each row independent of other rows helps database partitioning. This can greatly improve scalability.

The flexibility of the stored value could be a benefit for certain use cases. But such an agnostic approach has trade-offs that make it unsuitable for most applications. Clearly, there is no database support for joins between related data. The database is ignorant about what's stored for any key. It is not even possible to to perform simple updates without first reading the value into the application logic. For example, RocksDB cannot natively increment a counter or append to an array. The required Read-Modify-Write operations to update a value has obvious performance implications. It also introduces concurrency headaches if multiple threads update the same key.

When is no data model suitable for your application?

If you need very high performance.
You are dumping arbitrary data and the written records are independent from one another.
The data will always be written and read in full during runtime.

The document model

Example databases: MongoDB, CouchDB

The document model model represents data as a semi-structured object, commonly JSON or XML. This model is a more structured extension of the key-value store. There is a primary key, and the value is the semi-structured object. However, because this value can be a rich nested document, and include secondary indexes, its value is typically stored separately on disk to the indexed keys.

The document model is suitable if reading and writing self-contained data, which only has one-to-one or one-to-many relations. This allows the entire object to be stored together, in one location on disk. Consider this record for a holiday lodging website:

Most document databases store primary keys in a B-tree index, which points to the disk location where the document is written.

Here the fields contain one-to-one and one-to-many relations. By storing the object as a single document, access to the full object is provided through a simple, efficient, atomic query. No joins necessary!

Indeed, document databases typically have weak support for joins. It is discouraged to maintain any relation through foreign keys to other document collections. The preferred approach is to denormalise the data and embed it in all the relevant primary documents. By denormalising data, we remove the impediment of document joins and improve read performance. But there are downsides. Such an approach is detrimental if we expected the embedded data to change frequently. This is because the embedded data may be duplicated across many documents. So we need to update all of these if any of the embedded data is updated. On top of the obvious performance implications, this increases the chances of storing stale data, which could introduce bugs. So, a document model is ill-suited to modelling data with many-to-many relations.

Document databases are usually schema-less, and the data can have arbitrary fields and levels of nesting. The lack of schema may be an attractive feature in some instances. However, for most applications there is an assumed schema. If it isn’t enforced by the database, it will be enforced in the application code. Martin Kleppmann refers to this as “schema on read”. As this schema evolves, the application code has to accommodate both old and new schemas of the stored data. The result can be messy and difficult to maintain code. Therefore, I don’t believe the “flexibility” of a schema-less database provides a real benefit. It’s simply a property of the database to be aware of.

When is a document model suitable for your application?

Your data is self-contained (only one-to-one or one-to-many relations) and is typically queried as the whole object.
Your data truly doesn’t follow a fixed schema.

The relational model

Example databases: PostgreSQL, MySQL

The relational model separates related data into separate tables, as opposed to storing the entire object in one location. There is less overhead if only part of the data needs to be updated or read. Less data needs to be read into the database’s memory or sent over the network. Splitting an object into multiple tables isn’t limited to many-to-many relations. It can be useful for one-to-many, and even one-to-one relations too. The best schema design depends on the use case and expected query patterns.

Unsurprisingly, the relational model is useful for data that contains many-to-many relationships. Reading such data is more efficient as relational databases have good support for joins between tables. Also, separating objects into tables normalises the data. So our write efficiency is improved if we need to update a relation. Unlike unnormalised document databases, now we only need to update a single record, instead of every record that references that relation. Below we see the same property listing data as before, but split into a number of different tables. These reference each other through foreign keys.

SQL splits relations into separate tables. Each of these have a separate index for its primary key, and probably secondary indexes to aid with joins.

However, these relations impact write performance. Each table has a separate index, which needs to be updated every time the table is updated. There may be many secondary indexes to aid table joins. These, too, need to be updated on table writes. The relation model also limits performance if we frequently read or write the full object. Depending on the schema design, this may require the database to join multiple tables. While relational databases have good support for joins, this operation still carries a performance hit.

As relational databases improve support for JSON/XML data types, they can leverage some of the benefits of document databases. Certain fields may be defined as a schema-less JSON object, which makes it easier to evolve these as the app matures. An example is the details field in the above Listing table. Through this feature, we can gain some of the advantages of a document-oriented database. For this reason, Andrew Pavlo goes so far as to suggest that SQL and a relational model is the only form of database you should consider for your app.

When is a relational model suitable for your application?

You will frequently read only slices of the data, as opposed to requiring the full object.
Your data contains many-to-many relations. Particularly, if you expected this related data to be updated frequently.

Deciding on a database

Again, ask yourself these questions when considering what data model, and therefore database, best suits your application.

Will the written data follow a regular schema?

If not, maybe a key-value store or document database could be useful. But be mindful how your application code will manage evolving data.

Will the data have many-to-many relations?

If the data has many-to-many relations, it is likely a relational database will serve you best. If it doesn't, think about the other types of relations that exist in the data. Is there a benefit extracting these into separate tables? Often there is.

Is it useful to retrieve or update only part of the data? Or will you read and write it in full?

A relational structure is useful if only reading or updating part of the data. The database won’t need to read in the entire object when all that is required is a single field. The APIs of many document databases will allow you to retrieve and update a slice of data, but the database itself will need to read the full object into memory. For smaller applications, this overhead probably won’t be noticeable. But it is worth considering as your application grows. And for many key-value stores, updating a slice of data isn’t possible at all. The full object will need to be updated through the application code.

I have summarised the most common data models for online transaction processing (OLTP). Only consider other options if it is obvious these are inadequate. For example, a graph database would clearly manage relations between users on a social media platform better. And ridiculous scaling requirements could force you to consider models that can be better distributed. In such situations, research, research some more, and use first principles to guide your decision.

How to Setup Vim for Kotlin Development

Callum Lamont — Fri, 27 Dec 2024 21:05:03 +0000

The sad truth is that JVM languages are awkward to use with Vim. This is compounded for Kotlin. The user base is still smaller than Java's, so there are far fewer how-to guides to help set up your editor. Below should serve as a good crash course for developing Kotlin in Vim. Who needs to use IntelliJ 💁

So, to enable a reasonable Kotlin developer experience, we need to install:

A Kotlin grammar file to enable syntax highlighting.
The Kotlin language server (for IntelliSense and code navigation).
A code completion engine (optional, for Neovim) to auto-import dependencies.

These instructions have been written primarily for Neovim, but includes alternatives if you’d prefer to use the OG Vim.

Requirements

A Vim plugin manager.

You can manage plugins with Git submodules, but I've found this to be a painful experience.
Some examples are vim-plug, vundle, or, lazy.nvim.

An LSP client.

Neovim comes with a client. For Vim you will need to install one, such as CoC, LanguageClient-neovim, or vim-lsp.
Gradle.
Java 11+ and Kotlin. Currently there is an open issue for Kotlin versions greater than 2.0.0. Downgrade if you have any issues.

1. Syntax Highlighting

Because Kotlin isn’t as mainstream as Python or Java, many editors don’t have a default grammar to enable syntax highlighting.

Neovim

Neovim could use the default regex based grammar that Vim uses for syntax highlighting. But I recommended installing treesitter. This uses a concrete syntax tree to provide more semantic meaning to tokens, allowing enriched (and faster) highlighting.

Once treesitter is installed (using the instructions in the repository), install the Kotlin grammar.

:TSInstall kotlin

And update your init.lua file to turn on treesitter synax highlighting.

local treesitter = require('nvim-treesitter.configs')
treesitter.setup {
  highlight = {
    enable = true,
    additional_vim_regex_highlighting = false,
  },
}

You will have beautiful syntax highlighting when you next open Neovim 🌈

Vim

kotlin-vim is a reasonably popular plugin that provides syntax highlighting, among other functionalities. This enables highlighting by providing Vim a file of regex based Kotlin grammar. Once installed, it should enable syntax highlighting without further configuration.

The usefulness of the syntax highlighting also depends on your chosen colourscheme. Have a look at this collection to find new schemes to try out!

2. The Language Server

Installing the Language Server

The Kotlin language server is packaged in few places, but I recommend to build it from the source code. This helps you understand how the server and client are orchestrated. It will also aid debugging if anything goes wrong.

First, clone the repository. I suggest keeping all language servers in one directory $HOME/language_servers.

$ cd $HOME/language_servers
$ git clone git@github.com:fwcd/kotlin-language-server.git
$ cd kotlin-language-server

Check the build and tests work as expected.

$ ./gradlew clean build

Build the project and binaries.

$ ./gradlew installDist

There should now be an executable kotlin-language-server binary in $HOME/language_servers/build/install/bin.

For a large project, the Kotlin language server has a slow start up time (a few minutes) while it tokenises your entire project and stores these symbols in a database.

The server is also rather flakey. At some point while using it, it is likely to throw an error and stop working. Just close Vim and reopen your buffers again 💁

Configuring the LSP Client

Neovim
Install the nvim-lspconfig plugin to make configuration of the LSP client simpler. Then update your init.lua to tell Neovim which filetypes to use the language server for (i.e. .kt and .kts extensions). The LSP client will try to the start the sever by running the kotlin_language_server binary. You can directly point Neovim to the location of the binary, or include this directory in your $PATH.

local lsp = require('lspconfig')
lsp.kotlin_language_server.setup{
  filetypes = { "kotlin" , "kt", "kts"},
  -- If you don't update you $PATH
  cmd = { os.getenv( "HOME" ) .. "/language_servers/build/install/bin/kotlin_language_server" },
}

Vim
Follow the configuration instructions on the GitHub repo of your chosen LSP client (each one will be different). The Kotlin language server repository also provides some sample configuration for CoC and LanguageClient-neovim.

3. Completion Engine (Neovim only)

The builtin Vim omni completion engine is simple, but surprisingly useful. It will allow you to autocomplete any existing word in your open buffers (which is sufficient for a lot of use cases). But the completion menu won’t include options from your project dependencies.

With a language server set up, we have broader, project-wide context at our disposal. If we can plug this intelligence into our completion engine, it would then be possible to autocomplete and auto-import any method or class that exists in our project or its dependencies.

For this, we need to install a new completion engine: nvim-cmp. This engine uses completion “sources” (installed as separate dependencies) to populate the completion menu. So we also need to install cmp-buffer and cmp-nvim-lsp. Check out this tutorial by TJ DeVries for more info about how this plugin works.

Once those three plugins are installed, add this configuration to your init.lua. See the repository for more configuration options.

cmp.setup {
  mapping = {
    ["<C-n>"] = cmp.mapping.select_next_item { behavior = cmp.SelectBehavior.Insert },
    ["<C-p>"] = cmp.mapping.select_prev_item { behavior = cmp.SelectBehavior.Insert },
    ['<C-u>'] = cmp.mapping.scroll_docs(-4),
    ['<C-d>'] = cmp.mapping.scroll_docs(4),
    ['<C-o>'] = cmp.mapping.complete_common_string(),
    ['<C-e>'] = cmp.mapping.abort(),
    ['<C-y>'] = cmp.mapping.confirm(),
  },
  sources = {
    { name = 'buffer', keyword_length = 3 },  -- only start autocompleting after a few chars typed
    { name = 'nvim_lsp', max_item_count = 10 },  -- don't overpopulate list with symbols from LSP
  },
  -- Just for aesthetics
  window = {
    completion = cmp.config.window.bordered(),
    documentation = cmp.config.window.bordered(),
  },
}

Now, when you hit CTRL-n will open a completion menu. Pressing CTRL-y on an option will autocomplete with that symbol and (if required) insert the needed import statement at the top of your file 🎉

Wrap up

Following the above configuration should provide you syntax highlighting, LSP functionality (diagnostics, go to definition, etc.), and auto import.

Even with the above configuration, developing Kotlin in Vim isn't the smoothest experience. This is mostly due to limitations with the Kotlin LSP. I hope community support will improve this over time 🙂

Here is a fully functioning init.lua file for Neovim that includes all the configuration for the the above plugins.