Parallel product and implementation tracks

[aschrijver]

There are very interesting discussions taking place on Slack. Without implying anything about the approach taken (I truly have no opinion rn) I am seeing a lot of focus on technical implementation and wondering about the functionality that results for an App Dev. A tech-first exploration + elaboration and asking feedback on that may be best at this stage, idk.

Below I picked some nuggets of the conversation from Cosmonic (Kevin's) side that hint at product functionality to be delivered to the App Dev:

---

@autodidaddict concordance is a strict implementation of “Event Sourcing”.

the flow goes like this:

1. set up event catalog website
2. define events, commands, aggregates, flows
3. create a Rust wasmCloud actor
4. use the codegen macro to generate all of the code you need, including a trait that corresponds to the requirements of your event flow

we’re an opinionated framework that deliberately wants to fail your build if you don’t meet the requirements of your event flow contract. [..] you have a clear build-failing contract in your code

actor is either an aggregate or a projector or a process manager or generic event handler. which functions the actor is required to implement are defined by hidden, generated code contracts that come from the [Event Catalog] documentation website [..] [Event Catalog is] required for code generation. if you want to bypass codegen you don’t need it. the catalog houses the metadata for your commands, events, and components in a human-friendly way. Concordance can use that same info to generate all the code it needs.

in concordance’s opinion, the aggregate is a command handler, and an event applier [..] there’s a lot of time research evidence and suffering behind this opinion. Concordance aggregates are not DDD aggregates. [..] Aggregates [are stateless, cannot do side-effects] aren’t even allowed to make use of any other wasmCloud providers

[We want a Given When Then style of side-effect free behavior testing]

Also a remark about, umm.. let's say the Ubiquitous Language of Concordance 😜 :

I think we’re just struggling with naming and terminology far less than actual design patterns

---

In my discussion yesterday I hinted at this..

👉 Could we get to a situation where implementation vs. product development go more side-by-side? Know what's the desired functionality before it is being built, or in parallel to it being built? Explore the Concordance domain in a more non-technical fashion?

As an App Dev, before selecting wasmCloud/Concordance at a high level I'm facing this situation (I use terminology Creator/Clients):

1. As a Creator I have to address Needs of a Client in a particular Domain.
2. I have a Process to elaborate Needs with domain experts and turn them into a Solution.
3. I Provision (provide or host) the Solution into the Client's Domain.
4. I Maintain and Extend the Solution according to evolving Needs of the Client.

This is the backdrop against which I have to make the decision to go with Concordance or not. Given the breadth and scope of Concordance it is an impactful decision, and since Concordance takes an opinionated approach I will have to adopt my development processes accordingly. The easier it is to envision the impact, the easier the decision will be.

[aschrijver]

Concordance aggregates are not DDD aggregates.

Probably not saying anything new, but just in case there's confusion in our communication (also alluding to @yordis mentioning of "not being in OOP" in reaction to my other discussion topic)...

DDD = Strategic Design (non-technical, domain as text/models) + Tactical Patterns (going towards impl, e.g. with OOP or FP)

When you do a Google or DDG search you are overwhelmed with Tactical Pattern results. The statement that "Concordance aggregates are not DDD aggregates" relates to a tactical pattern, namely that when using OOP the aggregate is an object that has encapsulated state, and in Concordance that isn't the case and OOP isn't used. The statement isn't relevant in a (DDD) strategic design perspective.

In strategic design the Aggregate is simply a concept from the business domain. An interface to a particular bounded context (sub-domain) that forms a consistency boundary. The bounded context is always internally consistent. (The bounded context is an information model, but 'state' isn't really a concept. Text and diagrams describe behavior and business/domain logic).

• PS. Might watch DDD Strategic Design in under 15 minutes

When going into tactical patterns it is their implementation that give me as App Dev the experience where I don't have to worry about any infrastructure and plumbling concerns. I should be able to take the text and diagrams of the strategic design and almost literally transfer it into code. I code in the Domain Layer then, which by "inversion of control" has zero dependencies on other layers. So I should be able to both code and test (e.g. via Gherkin behavior tests) my bounded context / subdomain in complete isolation. This code should ideally even be 100% vendor-agnostic.

Then when Concordance comes into play it takes care of all my infra concerns, distribution, NFR's etc. This is coming along fine.

So in summary as App Dev I do 3 things to create a Solution:

1. Design the domain/CQRS/ES model (Event Catalog doc-first, probably with extra's)
2. Code the business/domain logic (Basic Rust or other supported language. Possibly BDD test-first)
3. Deploy using Concordance (Cosmonic or self-hosted)

And then to Maintain/Extend I keep doing these as part of / integrated with my solution dev process.