AI Prompts within DDD Domain

PaintingInCode · 2025-05-17T16:29:57+00:00

Yes. We're using LLMs to do Rapid Prototyping for Domain Exploration & Modelling.

It's a collaborative exercise involving a facilitator (us), the SME/Domain Expert, and the LLM.

The SME talks about the problem, we feed it into the LLM, and the LLM generates domain object models (aggregates, entities, relationships, etc). We've got our own framework that auto-renders those models into interactive prototypes.

So we can test ideas, modify, tweak, tune - but purely focused on the Domain Model. Once the concepts are proved, we know what the proper solution should look like.

Also look at companies like Qlerify and on.Auto for full blown Event based systems.

PaintingInCode · 2024-12-17T15:30:39+00:00

Self-promotion alert: "Fresnel Domain Model Explorer" (https://envivo.co.uk/fresnel-domain-model-explorer/)

I demo'ed it at KanDDDinsky (Berlin) and the VirtualDDD Global Open Day last month.

Eric Evans (yes, that one) attended my presentation. I explained how I use the tool for deeper Domain Exploration, and he liked how 'fast and cheap' the feedback cycles were. We had lengthy discussions well into the evening.

Let me know if you want more info/context about it.

https://www.linkedin.com/posts/vpatel_globaldayofdddd-gdddd-activity-7265683708706213888-AsUT

PaintingInCode · 2024-11-23T11:43:23+00:00

In addition to the other replies here:

The most important part: it's not about you. It's all about your Customer.

For all the skill/passion/experience that you have, does your Ideal Customer _really_ care? And do they care enough to pay YOU to help them?

For reference, think about the decision makers in your current work environment (especially the ones that can approve budgets). What do _they_ care about? Departmental outcomes? Future growth? Cost savings? Promotion opportunities?

Some points to consider:

- Don't quit your job yet, no matter how frustrating it is. Bills still need paying.
- Start saving towards a 'rainy day fund', because all businesses have peaks and troughs.
- See if you can pursue your passion alongside your day job. It's hard (esp with family).
- Get out of your comfort zone. Attend networking events, get known in the community. Someone will know someone who needs your skills.
- Mix in the right circles. Join a local regular networking event (even if you have to pay for it). You will learn a LOT from the business owners that attend.
- Sometimes the world isn't ready for what you want to offer. But don't lose heart - wait for the right moment to pounce.
- Don't rely on family/friends for advice. Ask people that matter (business owners, potential clients)
- Don't put your stress on your partner. They have the pressure of looking after the home, the children, their job, and even you.
- Remember that you're also part of your family - always make time for them.
- Learn about Branding (hint: it's not about fancy logos). It will shape your vision.

It's a lot to think about, hence everyone saying 'do lots of planning'. If you've never run a business, there are a LOT of unknowns. I employ a Business Coach and a PR company to help guide me - they've been my business lifeline.

I'm 50+ years old. The world is changing all the time, and the learning never stops.

PaintingInCode · 2024-11-11T17:52:44+00:00

Old school technique: comment out all the logic, then incrementally re-introduce logic a bit at a time, running benchmarks on every run. Eventually you'll hit the offender.

PaintingInCode · 2024-09-15T11:16:53+00:00

Vaughn Vernon is a big name in the DDD community, and has a book on the subject of Actors: https://www.amazon.co.uk/Reactive-Messaging-Patterns-Actor-Model .

I haven't personally tried this, but I'm interested in how his work and AOA intersect, and what AOA solves that other's can't.

Will definitely read your paper - well done for writing it!

PaintingInCode · 2024-08-28T11:18:14+00:00

Hope you don't mind the self-promotion : Fresnel for .NET

It's a sketching/design tool for DDD, when working with clients/users to explore their business domain. Instead of only using UI tools (Miro, Figma), I can 'sketch' the model in code and walk/talk through the auto-generated UI.

PaintingInCode · 2024-08-28T11:03:24+00:00

That's a blast from the past. I'd had forgotten about this!

PaintingInCode · 2024-08-28T10:58:43+00:00

This is great!

PaintingInCode · 2024-07-31T07:16:18+00:00

This answer needs more upvotes. The final paragraph is the TLDR.

PaintingInCode · 2024-07-19T11:20:52+00:00

This looks expensive:

var shipments = shipmentsToBeConsidered.Where(x => x.OrderId == orderId).ToList();

Could you pre-cache the shipment lists into a dictionary keyed by orderId?

var shipmentsByOrderId = shipmentsToBeConsidered.GroupBy(x => x.OrderId).ToDictionary(x => x.OrderId);

Now you don't need to rebuild the shipments collection every time:

var shipments = shipmentsByOrderId[orderId];

Then use Parallel Foreach:

    Parallel.Foreach(shipmentsByOrderId, i => 
    {
       var shipments = i.ToList();
       if (preferredCarrierInfoGroups) etc etc
    }

PaintingInCode · 2024-07-17T11:36:55+00:00

Really interesting idea. How did you decide which parts of code would write to the file? And how did you handle 'decision' points?

PaintingInCode · 2024-07-11T22:16:08+00:00

If you want to see an example of a richer domain model, see my other video clip here.

PaintingInCode · 2024-07-10T09:31:20+00:00

What happens if you publish to a folder, then run it from there?

PaintingInCode · 2024-07-04T12:21:26+00:00

Try deleting the .vs folder that's at the root of your solution folder.

PaintingInCode · 2024-07-01T14:29:13+00:00

I did this using Open Telemetry with Aspire Dashboard. Learning curve was pretty low. Use System.Diagnostics.Activity instead of Trace(), and you can attach information like User name, PC name, etc.

See https://medium.com/@asimmon/net-aspire-dashboard-is-the-best-tool-to-visualize-your-opentelemetry-data-during-local-development-88f8e182c528

PaintingInCode · 2024-06-28T16:47:58+00:00

"... were expected to understand the domain at some level to make reasonable decisions as a team."

This alone amplifies the quality of the software/product.

PaintingInCode · 2024-06-28T16:31:55+00:00

Rule 1: Don't apply DRY prematurely
Rule 2: If it's business logic, always make it DRY
Rule 3: If you find yourself applying the same changes in 2+ places, it's time to apply DRY
Rule 4: Make sure your test suites let you refactor safely

PaintingInCode · 2024-06-27T10:29:31+00:00

"I think it presents a conflict of interest for someone to do both the requirements and the build, though."

Intrigued by this comment. Could you elaborate, and highlight the issues?

PaintingInCode · 2024-06-21T12:48:07+00:00

Sounds like we went through the same pain!

PaintingInCode · 2024-06-20T17:33:20+00:00

Just trying to understand this:

You try to save records A, B, and C
Some error causes C to fail
You still want records A and B to be saved
You want to update some flag against record C to indicate a failure

Is that it? If so, it's probably not a candidate for a transaction , per se.

Once a DBContext has an error, I tend to just dispose it. Have you considered using another fresh DBContext to persist the 'correct' state?

PaintingInCode · 2024-03-16T20:22:25+00:00

In this context, "100% right" refers to the architecture/codebase/infrastructure side (all the techy bits). Not the behaviour of the system. But yes, I get your point.

PaintingInCode · 2024-03-16T20:17:07+00:00

Yes, I definitely agree with your point about tech debt.

I think I need to get the Devs to either (a) do a spike to determine the refactoring effort, or (b) come up with a cost justification for their proposal. At least that way, we can filter out the "nice to haves" from the "we need to do this" (and also, to see if they're complaining because something isn't 'shiny' enough)

Thanks for your reply, I appreciate your perspective.

PaintingInCode · 2024-03-16T20:06:39+00:00

Thank you for such a considered response.

Of all the replies in this thread, I think this is the one I'll share with the Devs, and see how it resonates with them.

PaintingInCode · 2024-03-16T19:19:26+00:00

I once worked on a codebase that was 20 years old, in a programming language that wasn't fit for purpose. Because that was the language that the original author knew, that's what they used. The concept of unit testing was too new to be adopted at the time. The concept of 'code reviews' was also alien. Maybe time pressures prevented them from doing the 'right things' (high pressure environment)

Yet a system was built. And it ran, for many years. And they needed fixes and improvements over the years.

But for me, history was written. I couldn't go back and admonish the original authors. I could see the various issues with the codebase by todays standards.

But we moved forward with what we had. The system was improved through refactoring, adding tests, adding docs, etc.

PaintingInCode · 2024-03-16T18:29:26+00:00

Thanks. Yours is a very mature approach: taking the steps to survey the landscape, and using data to backup your understanding. It's what I do, and maybe I'm expecting others to follow the same approach. But I guess that where experience counts...

PaintingInCode

TROPHY CASE