A modern programming language that makes developers happier.

kotlinlang

set the channel description: Applying Domain Driven Design in Kotlin

doesn’t look like there’s much going on her e

cross post from <#C09222272|random>
<https://kotlinlang.slack.com/archives/C09222272/p1619037195078200>

Have you heard of <https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577>

Yep, thank you so much for the suggestion :pray:

Hello guys! Looking forward to your feedback. The library provides just enough tactical DDD patterns, optimized for event-sourcing and  CQRS by practicing functional programming and OOP <https://github.com/fraktalio/fmodel/blob/main/README.md>

You can find demos/examples here: `<https://github.com/fraktalio/fmodel-demos>`

anyone familiar with <https://contextmapper.org/>?

Haven’t seen that before but looks interesting.

Functional &amp; Reactive Domain Modeling with Kotlin - <https://fraktalio.com/fmodel/>

Check out the blog series: <https://fraktalio.com/blog/the-template.html>

Hit that :star: on GIthub <https://github.com/fraktalio/fmodel> !

Is there any mobile (android specific) samples?

FModel 3.0.0 multiplatform has just been released <https://github.com/fraktalio/fmodel/releases/tag/v3.0.0> `domain-modeling` / `event-modeling` / `event-sourcing`

Bottom Navigation Design                                  hi every one as you can see my bottom navigation work compelitly fine but I cant see the icon on design what can I do about this problem?
Thread in Slack Conversation

<https://kotlinlang.slack.com/archives/C0BJ0GTE2/p1663250430308729>

i do not really get what fmodel actually IS. is it framework? a library? an example implementation?
If not the latter - is there an example implementation?

It is a set of libraries. The most important one is a `domain` library, holding components Decider, View, Saga. You can use these components to implement core logic/computation. This library is using functional paradigm and it is very much generalized throug parametrization (C=Command, E=Event, S=State). `application` modules are mainly interfaces/ports showing different ways of composing or orchestrating these domain components: eventsourcing or traditional state storing are available out of the box.  `application` modules are more opinionated as they are pushing towards specific architecture clearly separating effects (saving. fetching) from you core logic/domain components. You can choose not to use `application` modules/libs and implement your own application layer that will run your domain (in that case it serves as an example or inspiration). It is not a framework and it will never become a framework.   Find the online playground here <https://fraktalio.com/blog/playground> and some examples here <https://github.com/fraktalio/fmodel-demos> There is a series of blog post <https://fraktalio.com/blog/posts>

Got it, thank you :smiley:
I'd suggest to write these words at the beginning of the readme. I was hesitating to read all of it because I had no clue what this all is about.
But I think it sounds interesting!

Good point, thank you, I was thinking to do this. Havent find the time :disappointed: It is very interesting journey for me and I learned a lot. I hope you will stick till the end of README and explore the examples.

Yes, now that I understood what this repository is about i will give it a try. I implemented some of the DDD patterns and some sourced entities myself and am interested how you solved it :smile:

This idea is not mine, I rather liked it a lot. I’m long time DDD practitioner :slightly_smiling_face: This video inspired me a lot <https://www.youtube.com/watch?v=kgYGMVDHQHs>

Thanks for the link, guess it'll give some more context to the idea :bulb:

A new Reference Guide for `Fmodel` library is published! <https://fraktalio.com/fmodel/>

`Fmodel` aims to bring functional, algebraic and reactive domain modeling to Kotlin.
It is inspired by DDD, EventSourcing and Functional programming communities, yet implements these ideas and concepts in idiomatic Kotlin, which in turn makes our code
• less error-prone,
• easier to understand,
• easier to test,
• type-safe and
• thread-safe.


<https://mastodon.online/tags/Fmodel|#Fmodel> is an open source software, publically available at GitHub <https://github.com/fraktalio/fmodel|https://><http://github.com/fraktalio/fmodel|github.com/fraktalio/fmodel>

It is a generalized and abstract template for your business flow. You can use <https://mastodon.online/tags/SpecificationByExample|#SpecificationByExample> to discover that flow and distill the requirements <https://fraktalio.com/fmodel/docs/domain/discovering-the-domain>

EventModeling by example on Miro: <https://miro.com/app/board/o9J_ktrZ1rU=/>

It's been a while since we've had a post about Fmodels.
I have also started using Miro for event modeling with Product Owner and Product Design team.
We decided to designate the event model we created in Miro as SSOT.
The Product Design team says it's easy to understand the data and behavior of the system because it's visible.
Recently, I have been studying hard to use your fmodel for team projects.
In order to understand your fmodel code, I need to learn
kotlin, functional programming (Monad, Arrow.kt), and ES.
It's not easy because it's all new to me, but it's fun and I'm looking forward to the point where I can use it skillfully and it will have much more advantages than traditional development methods.

Thank you.

Just wondering why you had to split the commands and events decide and evolve... they end up usually having the same data in them, isn't that just too much boilerplate for a lot of cases?

Hi Dave, events are central in this model, and they represent the most granular `state change` of the system/part of the system. Traditional/StateStored systems are also implicitly using events, just we are not focusing on them in this case, and it is not obvious as they are conceived as simple delta (I fetch the current state from DB, I update that state with `something`/`delta`, I store it back to DB). So, the events are discarded in this case, and only the final state is what you store in DB. By having these two functions separately you keep these two options open: 1. Traditional/State Stored system (storing the State/S, events/E are discarded), 2. EventSourced system (storing events/E, State is discarded) depending on how you choose to compose these two functions latter: 1) <https://github.com/fraktalio/fmodel/blob/fa1e7e72049e43aba2531de1dc91d0f21d1eb576/application/src/commonMain/kotlin/com/fraktalio/fmodel/application/StateStoredAggregate.kt#L37|https://github.com/fraktalio/fmodel/blob/fa1e7e72049e43aba2531de1dc91d0f21d1eb576/[…]kotlin/com/fraktalio/fmodel/application/StateStoredAggregate.kt> 2) <https://github.com/fraktalio/fmodel/blob/fa1e7e72049e43aba2531de1dc91d0f21d1eb576/application/src/commonMain/kotlin/com/fraktalio/fmodel/application/EventSourcingAggregate.kt#L27|https://github.com/fraktalio/fmodel/blob/fa1e7e72049e43aba2531de1dc91d0f21d1eb576/[…]tlin/com/fraktalio/fmodel/application/EventSourcingAggregate.kt>

We want to be very formal with every change in our information system, and that is why we focus on events and model them in our design. Whether you choose to store them or not, it is on you. I choose events.

<https://miro.com/app/board/o9J_ktrZ1rU=/>

I see, that makes sense for those that need event sourcing, but it would still add an extra layer for those that don't... but thanks for the explanation! I'll keep this lib in mind if I need event sourcing :ok_hand::skin-tone-3:!

Sure thing. Event sourcing is where it shines, indeed! Please mind that discussing Events in discovery phase  of the project is also very valuable, nevertheless you don't store/use them.

That's true in all state machine implementations, but the separation of Command/Event in yours adds the bonus of Event Sourcing... when mixing them up, I'm starting to see that it would be harder to implement that.

I dont see this as mixing, rather as constituting clear relation (and being very formal about it) between `list of events` and the final `state` with function `evolve`. This function is actually mapping events into a state by folding/reducing. You might see this as an overhead, I rather see  it as a missing relation in our design and thinking, and Fmodel is trying to make it back.

Screen Shot 2023-07-11 at 1.49.08 PM.png

Screen Shot 2023-07-11 at 1.48.38 PM.png

I have a question about *Aggregate*.

I am studying your code. (<https://github.com/fraktalio/fmodel-spring-state-stored-demo>)
I want to add an entity called Agency to your code and create a function to create and view entities.

I read your blog post and README.md file and created command, view, event and decider and view for Agency. I also created test code and checked that it runs successfully.

I extended the [aggregate code](<https://github.com/fraktalio/fmodel-spring-state-stored-demo/blob/a40f5ba117d3a5e56b7fe16108a218af495e8503/src/main/kotlin/com/fraktalio/example/fmodelspringdemo/application/Aggregate.kt#L50>) like below.

*Question)* I'm wondering if it's correct to extend it like this.

Another Question

I want to know more about a function called *dimapOnState*. What does the dimapOnState function do? Even looking at the function definition section, I'm not sure.

By the way, I'm new to functional programming, so I bought this book yesterday and am studying it. :slightly_smiling_face:
<https://www.manning.com/books/functional-programming-in-kotlin>

Hi Liam. Indeed this is correct. You focus on implementing your Deciders. Then, you choose to combine them on the Application layer as you find fit. Your choice was to aggregate/combine them under one/same aggregate, which is fine (I call this monolith-orchestrated situation <https://fraktalio.com/fmodel/docs/application?system-type=state-stored&amp;style=monolith>). FYI, you can consider to distribute it differently: Aggregate1=order+restaurant; Aggregate2=agency  <https://fraktalio.com/fmodel/docs/application?system-type=state-stored&amp;style=distributed>

`dimapOnState` is a Decider function that will map that Decider to another Decider with another type for the State. Have a look at this example <https://fraktalio.com/fmodel/docs/domain/aggregating-the-behaviour?component-type=decider>

For example, if you combine two (or three) deciders into one bigger, you would end up in the new Decider:

```val orderDecider: Decider&lt;OrderCommand?, Order?, OrderEvent?&gt; = orderDecider()
val restaurantDecider: Decider&lt;RestaurantCommand?, Restaurant?, RestaurantEvent?&gt; = restaurantDecider()

// Combining two deciders into one big decider that can handle all commands of the system.
val allDecider: Decider&lt;Command?, Pair&lt;Order?, Restaurant?&gt;, Event?&gt; = orderDecider combine restaurantDecider```

Notice how this allDecider/new decider is modeling the State as Pair. To improve on that you can apply `dimapOnState` to this Decider to get new Decider

```val newAllDecider = allDecider.dimapOnState(
            fl = { myDomainSpecificType: MyDomainSpecificType -&gt; Pair(myDomainSpecificType.order, myDomainSpecificType.restaurant) },
            fr = { pair: Pair&lt;Order?, Restaurant?&gt; -&gt; MyDomainSpecificType(pair.first, pair.second) }
        )```

The `newAllDecider` is of type `Decider&lt;Command?, MyDomainSpecificType, Event?&gt;` now, which might be fitting your Domain naming conventions better

You might consider introducing a variable `newDecider` to combine many deciders into one bigger: `val newDecider = decider1.combine(decider2).dimapOnState(...).combine(decider3).dimapOnState(...),` and then use that variable as a parameter to the Aggregate constructor function.

BTW, I am thinking to rename these functions to `map` These are essentially map functions that you might find on the List type (or many other types) in Kotlin that are mapping a List&lt;Int&gt; into List&lt;String&gt; for example. In our case we have a Decider (not List) type that you can map. For example: Decider&lt;C, S, E&gt; into Decider&lt;Cn, S, E&gt; with function `_fun_ &lt;Cn&gt; mapLeftOnCommand(f: (Cn) -&gt; C)`

If you are interested, provide a PR (adding Agency decider/entity, as you just suggested) on <https://github.com/fraktalio/fmodel-spring-state-stored-demo>, so we can collaborate on it together. It does not have to be perfect, it can be a draft version at first. We can merge it latter, and improve the example/demo with more cases (I can add distributed case).

Hi Ivan
Thank you so much for your quick and kind response.
I'm glad to hear that the code I added is not wrong.
As I mentioned before, I've only been studying your code for a short time.
Despite your kind response, I still didn't fully understand the `dimapOnState` function. I think I need to study more about FP. :slightly_smiling_face:

I will take your advice and provide PR when necessary.
I think it might be a PR that doesn't meet your expectations, but I'll be brave enough to suggest it.

Dont mind my expectations. I would be happy to collaborate with you, so we can learn more. It will help me improve the documentation.

The documentation is not tapping into the FP and Category Theory very much. I did not want to overwhelm people with too much of details up-front. By reading your Slack messages I realised I should improve on that side and provide references for engineers that would like to know more. For example, what is contravariance and covariance, what is functor and what is profunctor. `dimapOnState` defines Decider as a profunctor, for example.

If you want to learn more about this algebra tap into the 5 parameter decider (which is internal): <https://github.com/fraktalio/fmodel/blob/main/domain/src/commonMain/kotlin/com/fraktalio/fmodel/domain/internal/InternalDecider.kt>

You will notice that we have two parameters for State: `Si`(input position/contravariant position), `So`(output position/covariant position), two parameters for Event `Ei`(input position/contravariant position), `Eo`(output position/covariant position, and one for the Command `C`(input position/contravariant position). So we are very explicit about the variance of the type parameters, which makes them 5 in total.

input/contra position parameter can only be found on the left side of the methods/functions that are defined in Decider.

output/co position parameter can only be found on the right side/result of the methods/functions that are defined in Decider.

I will try it with *distributed styles* as per your advice.
&gt; FYI, you can consider to distribute it differently: Aggregate1=order+restaurant; Aggregate2=agency  <https://fraktalio.com/fmodel/docs/application?system-type=state-stored&amp;style=distributed> 


<https://kotlinlang.slack.com/archives/C0BJ0GTE2/p1689362608022449>

Screen Shot 2023-07-30 at 11.48.11 PM.png

I have a question about the ability to query View.
Sometimes I need to create complex statistical data by querying multiple entities stored in the DB as read-only.
What is the best practice in this case?
The system I am developing has a Courier aggregate and an Order aggregate.
I'm trying to develop an API that aggregates the entities in these two aggregates, averages them, and sums them.
In this case, the functions or classes that do the aggregation should be located in the Application layer.
Ivan, if you have any guidance, I would appreciate it.

For now, I've added some lookup logic in adpater.web as shown below.

Hi Liam. Is this State stored aggregate or event sourced aggregate?

OK. The state stored aggregate has only one model/db-schema, for writing and reading. Event sourced aggregate is storing events (command model) and you have materilized views (query model). So, event sourced aggregate is enabling CQRS pattern and you are able to create many different query models by using Views, per need. Usually these query models are denormalized and optimised for specific case: serving the data to some web page or doing some complex reporting. But, you are not limited to only one canonical model for your system, you can have many of these models/db-schemas on the View/Query side. That is one of the great values of event sourcing and CQRS.

State stored aggregate has only one model/repository for writing the state and querying the state. It is not publishing events, so the CQRS (Materialised Views) can not be utilised in that regard, and you are only limited to query the tables/repositories of that aggregate state.

You still have some tactical options to improve the reading of the aggregate tables. Aggregate repository can be one repository used by your aggregate to fetch and store the state/data. You are free to create new repositories (or use JDBC template) to query the same tables per your need (so you dont do the aggregation in the application memory, let the DB do most of the job. Think of: joins and SQL functions that can do aggregation, summing, maxing for you, on the DB level). The implementation of these new repositories should be in adapter layer (adapter.persistence). The interfaces of these repositories should be in application layer/port. The repository interfaces could be injected into your controller (adapter.web)

First
I have read your kind response several times to understand it.
The product my team is building is likely to have frequent changes in requirements and we need to generate a variety of reports.
After reading your answer, it seems that my team's product needs to use Event sourced aggregates.
I chose State stored aggregate because it has a lower learning curve than Event sourced aggregate, but now I need to seriously think about and start learning the Event sourced aggregate approach.

Second
The tactical options you provided in response to my question made me think more about the port / adpater pattern. The guide you provided with specific examples gave me another way of looking at it.

Thank you.

No problem Liam. I am glad I helped. It worths learning more about event sourcing pattern and using Event sourced aggregates instead. Only in this case we collect the full history/events of everything that happend in your system. Events are central in this design and being considered as an API (not thrown away like in the case of the StateStoredAggregate) that can be advertised to any downstream component. It will unlock MaterailizedViews (CQRS) and SagaManagers (Integrations). It will focus your architecture towards Event-Driven style. <https://fraktalio.com/blog/integration-of-event-driven-systems.html>