Agape-Apps: Building Baruch Together

[Jonathan1]

Zero Version Stress

In many distributed systems, versioning is a hidden source of friction.

• One device updates.
• Another does not.
• A schema changes.
• Suddenly everyone must upgrade.

Baruch was designed differently. It allows phones, tablets, desktops, different app versions to synchronize seamlessly — without forcing everyone to upgrade at the same time.

• No version panic.
• No synchronization lockouts.
• No emergency update requirements.

The Core Principle: Versioned Events

 

Baruch does not synchronize raw database tables. It synchronizes versioned domain events. Instead of sending “state,” it sends structured, versioned messages.

For example:

Congregation_v1

Each event contains:

• A versioned DTO (Data Transfer Object)

• Serialized event data

• Metadata describing origin and event type

Every update — create, modify, remove — is wrapped in a versioned message. This is crucial. Because versioned messages allow older clients to understand newer data structures — as long as compatibility rules are respected.

 

Backward Compatibility by Design

When Baruch evolves, the system does not “break” older clients. 
Why? Because:

• Event types are versioned

• DTOs are versioned

• Mappers are controlled

• Unknown fields can safely be ignored

For example:

Congregation_v1

If a future version introduces:

Congregation_v2

Older clients that only understand v1 can still process:

• Shared fields

• Known structure

• Existing properties

Newer fields do not disrupt older versions. This is classic backward compatibility. 
But implemented deliberately.

 

Why Database Schema Changes Don’t Force Updates

In traditional systems, when a database schema changes:

• Clients must update immediately.

• API contracts break.

• Serialization fails.

• Users are blocked.

Baruch avoids this entirely. Because:

1. The database schema is internal.

2. Clients never consume raw schema.

3. Clients consume versioned events.

Even if the database evolves internally:

• Events remain stable.

• DTO versions remain supported.

• Mapping layers handle transformations.

This decouples database structure from client compatibility.
Which means:

A schema change never requires every device to update simultaneously.

 

How Synchronization Actually Works

Here’s the simplified flow:

1. A device issues a command.

2. The command creates a versioned event.

3. The event is stored.

4. Other devices fetch unpublished events.

5. Each event is deserialized into its DTO version.

6. The appropriate command handler reconstructs the domain model.

Example conceptually:

ModifyCongregationCommand
→ EventCreateCommand
→ Serialize DTO_v1
→ Store Event
→ Other device processes event
→ Map DTO → Domain → Entity

The processor:

• Checks idempotency

• Applies the event

• Marks it as processed

Even if a device is one or two versions behind, it can still:

• Deserialize known fields

• Ignore unknown ones

• Apply safe changes

No version lock.

 

Event Versioning Makes Parallel Versions Safe

This means:

• A mobile phone can run an older version.

• A tablet can run the latest version.

• A desktop can be somewhere in between.

All three can:

• Create events

• Process events

• Stay synchronized

Because the event contract is stable and versioned. The system does not assume:

“Everyone must upgrade now.”

Instead, it assumes:

“Different versions will coexist.”

And it is built to support that.

 

Idempotency Protects Against Duplication

Each event is processed only once. Even if:

• Network retries happen

• A device reconnects

• Events are replayed

The processor checks whether an event was already applied. This ensures:

• Safe replay

• No double writes

• No corruption

• Reliable offline synchronization

This is critical for mobile environments.

 

Why This Architecture Matters for Congregations

From a user perspective, this translates into:

• No forced update weekends

• No emergency patch rollouts

• No “please update before you can continue”

• No version mismatch errors

Updates can roll out gradually.  Devices can update when convenient.
The congregation keeps working.

 

Separation of Concerns: The Real Strength

Baruch separates:

• Domain model

• DTO layer

• Database entity layer

• Event layer

• Command handling

• Synchronization processing

Because of this separation: Internal change does not break external communication.

Baruch is not just cross-platform. It is cross-version safe.
Every device — mobile, tablet, desktop — can:

• Run different versions

• Continue synchronizing

• Process events correctly

• Remain stable

Without forcing immediate upgrades. Without version chaos. 
Without operational stress.

Baruch synchronizes devices through versioned domain events — making database evolution invisible to users and eliminating forced upgrade cycles.

[Eryk]

My brother, the concepts you present sound very good, but (honestly) it all looks like it's AI generated. Keeping it simple will help the rest of us understand (and accept) more readily ;-)

[Jonathan1]

11 hours ago, Eryk said:

My brother, the concepts you present sound very good, but (honestly) it all looks like it's AI generated. Keeping it simple will help the rest of us understand (and accept) more readily 😉

 

I understand, but let me explain my approach. At the beginning of this thread, I explained that I'm a one-man army. I invest a great deal of time in achieving a very high level of quality for this software. Parallel to this, I also want to properly document how I do this. This is only possible with full AI support.

 

I use AI support throughout my entire workflow. This is essential when you're developing such a large project on your own. I'm building this documentation in parallel with my other programming work. I don't have the time to create a personal document for this. I use AI to document what I do, and I also have it create diagrams and images to describe it. I don't know how else I could achieve this in such a short time.

 

Ultimately, it's all about the result of how the software works. I guarantee a very high level of software quality. I don't need the documentation myself to achieve this. It's simply to inform others about how I realize the software. I want to be very transparent about this, and AI is my best friend in this.

[Jonathan1]

On 2/18/2026 at 9:29 PM, Jonathan1 said:

Dear Brothers & Sisters, I need your help and input.

What is in your opinion the best layout for a main congregation screen?

Shall I create a dashboard with the congregation status and seperate maintenance screens? Or a combined screen with dashboard parts and maintenance parts?

 

 

Sometimes I explicitly ask for user input on some components. This mainly concerns how the screens work and the best layout I can implement.

 

Other components concern the core of the system. Here, I explain how the system works and its advantages. This last component is not easy to understand. You really need to be a software architect to properly assess it. Nevertheless, I choose to share these parts and architectural choices as well.

 

The audience of this forum is very diverse. Some brothers are technically proficient and have a better understanding of the lower layers of software, design patterns, and software topology. Others approach the software more functionally and can provide input on user interaction. Both are essential for a good end result.

[Eryk]

I am not against the use of LLMs (Large Language Models ~ "AI"), but at least prompt your agent to use simple and concise terms :-)

 

In the end, the "proof is in the pudding", as they say.

[Jonathan1]

A Reactive, Privacy-First Architecture

When developing Baruch, architecture is not just a technical concern — it directly affects trust, stability, and peace of mind.

With Baruch, I've made a deliberate architectural shift. A foundation that is:

• Deterministic

• Privacy-conscious

• Offline-first

• Maintainable long-term

Here I explains the architecture behind Baruch — and what it means for elders, planners, and publishers who use it.

State-Driven, Not Event-Driven

Traditional software applications often grow organically:

• UI events mutate domain objects

• Services update databases

• Sync logic reacts afterward

• State is spread across layers

Over time, this leads to hidden side effects, fragile flows, and increasing complexity.

Baruch takes a different approach. Instead of letting changes happen everywhere, we centralize change into structured state modules.

 

Baruch v2 is built in six clear layers:

1. User Interface Layer

The UI layer is intentionally simple. It:

• Sends user intents (e.g., “NameChanged”)

• Reflects application state

• Handles layout and visual validation

It does not:

• Contain business logic

• Manage persistence

• Handle synchronization

This keeps screens predictable and stable.

---

2. Reactive Module Layer

Each bounded context — such as Congregation, Assignments, or Families — has its own module. Each module contains:

• Immutable State (record types)

• Intents (user-driven actions)

• A pure Reducer (state transition logic)

Every change flows through a single deterministic pipeline:

Intent → Reducer → New State

 

No hidden mutations. No silent side effects.

This makes the system transparent and testable.

---

3. Domain Core Layer

This is where the real congregation logic lives. Examples:

• Assignment calculation engine

• Qualification rules

• Rotation algorithms

• Availability rules

The domain layer is:

• Pure

• Side-effect free

• Independent of UI and storage

Given the same inputs, it always produces the same outputs.

This is essential for fairness and reliability in planning.

---

4. Application Services Layer

This layer orchestrates use cases:

• Generate next schedule

• Import existing data

• Export reports

• Migrate data

It coordinates modules, domain logic, and persistence — but contains no UI or business rules itself.

---

5. Persistence & Sync Infrastructure

Baruch is designed to be offline-first.

Local storage is the primary source of truth.

Cloud synchronization:

• Uses anonymous identifiers

• Does not store personal identifiable information (PII) - implicit GDPR compliant

• Operates as a synchronization layer, not a master database

This greatly reduces risk exposure.

---

6. Privacy Boundary

A key architectural decision in Baruch is explicit separation between:

Local-only personal data

• Names

• Phone numbers

• Addresses

• Notes

and Cloud-safe data

• Anonymous IDs

• Assignment structures

• Scheduling metadata

By design, sensitive personal data is never centralized in the cloud.

Why This Architecture Matters for Us

Architecture is invisible — until it fails.

 

Here’s what this approach means in practical terms for elders and congregation members.

---

1. More Reliable Scheduling

Because planning engines are deterministic:

• The same input always produces the same schedule

• There are no hidden side effects

• Assignments are calculated consistently

This improves fairness and predictability in congregation responsibilities.

---

2. Fewer Errors and Surprises

When state changes are centralized:

• There are fewer race conditions

• No unexpected overwrites

• Reduced risk of conflicting updates

This leads to smoother coordination.

---

3. Offline Stability

Baruch does not depend on constant internet access.

If the internet connection fails:

• Planning continues

• Data remains accessible

• No interruption to congregation work

This is especially important in regions with unstable connectivity.

---

4. Reduced Privacy Risk

Because personal data remains local:

• There is no central database containing congregation member details

• The impact of a cloud incident is significantly minimized

• Compliance complexity is reduced

For elders, this lowers administrative and legal burden.

For members, it increases trust.

---

5. Long-Term Maintainability

A deterministic, modular architecture ensures that:

• Features can be added without destabilizing existing ones

• Bugs are easier to isolate

• Future modules can integrate cleanly

This protects the investment congregations make in adopting the system.

---

6. Foundation for Future Growth

Baruch’s architecture supports:

• Undo/redo capabilities

• Advanced reporting

• Smarter assignment engines

• Expanded mobile capabilities

Without needing to redesign the core again.

 

Technical note: I use MAUI.NET in combination with Rx.NET for implementation.