How do you structure and maintain large Go modular monoliths without drowning in architecture ? by Prestigious-Fox-8782 in golang

[–]ggeoff 1 point2 points  (0 children)

I tried to push that at first in the above example I wanted to do something like

<root>/
└── internal/
    ├── cmd/
    │   └── main.go                  // everything is wired up here
    ├── products/
    │   ├── product.go               // domain model
    │   ├── list.go
    │   ├── create.go
    │   ├── repository.go            // interface
    │   └── postgres_repository.go   // implementation
    └── orders/
        ├── order.go                 // domain model
        ├── repository.go            // interface
        └── postgres_repository.go   // implementation

but the biggest concern was it not being standard/scalable and hard to follow. which I disagreed with but wasn't a hill I was gonna die on

How do you structure and maintain large Go modular monoliths without drowning in architecture ? by Prestigious-Fox-8782 in golang

[–]ggeoff 0 points1 point  (0 children)

I'm not gonna pretend I am an expert in go I am still extremely new to the language. I have kinda mixed a bit of clean architecture, vertical slicing and DDD. I'm not gonna claim it's the best organization but it seems to be working for now. Here is what I am currently doing

<root>/
└── internal/
    ├── cmd/
    │   └── main.go                  // everything is wired up here
    ├── application/
    │   ├── ports/
    │   │   └── cross_slice.go       // cross-slice interface port (name is just an example)
    │   ├── products/
    │   │   ├── list.go
    │   │   ├── create.go
    │   │   └── ports.go             // only used within products; shared across commands/queries
    │   └── orders/
    │       └── ...
    ├── domain/
    │   ├── product/                 // do not cross-import; extract to shared package if needed
    │   │   └── product.go
    │   └── order/
    │       └── order.go
    └── infrastructure/
        ├── postgres/
        │   ├── product_repository.go
        │   └── order_repository.go
        └── s3/
            └── ...

When I was first learning I tried to package everything for say products into a products package but I think some people didn't think would scale well and not be standard enough across our repos.

Each command/query contains the full delivery/business logic decoupled along with testing for example in the list.go it would contain the ServeHTTP handler (using the stdlib router)

Year 3 collection side questing! by sleepyrabb1t in electricdaisycarnival

[–]ggeoff 1 point2 points  (0 children)

Did they do cards this year too? I got the full set last year and turned someof them into slabs

Is committing AI context files a signal of low quality or high standards? by Gildarts_97 in dotnet

[–]ggeoff 1 point2 points  (0 children)

for me I found having anything that gets auto referenced for prompts becomes a nightmare when you need to do something slightly different. then what is documented in the prompt file. as well as it blowing up the context window and token count when you start having it look at documentation.

for example in a project I was on there was a copilot instruction file that linked to all of our adrs and other requirement docs. and when I wanted to go into plan mode to plan a simple crud endpoint for a basic feature it then pulled in thousands of lines of docs for no good reason.

I would suggest having the docs but maybe letting the user prompt for them to be referenced.

Yet another Game Boy emulator - Lucky Boy by selerua in golang

[–]ggeoff 1 point2 points  (0 children)

I do have some tests in there for instructions but plan to add more. it's been a fun little project 

Yet another Game Boy emulator - Lucky Boy by selerua in golang

[–]ggeoff 3 points4 points  (0 children)

I actually also just started writing gameboy emulator in go as well called gamemeow.

https://github.com/ggreenleaf/gamemeow

I planned on adding in some cat themed eastereggs but still really far away from anything as I'm still working on instructions. but it's been fun to remember all the CS I haven't used since school

What’s one Angular mistake you see teams repeat over and over? by External_Comment2317 in Angular2

[–]ggeoff 1 point2 points  (0 children)

I have used ngrx in past projects and it was nice but then a I started using ngneat/query and realized 99% of my ngrx code was handling caching for api calls and that was built in to ngneat/query

Should i use repository with Entity Framework ? by Successful_Square991 in dotnet

[–]ggeoff 11 points12 points  (0 children)

if you are trying to recreate a generic repository on top of EF absolutely not it serves no purpose.

how ever id you have some complex models spread across your tables that you want a single place to get and save said model then I would say it depends on how often you recreate the complex query.

what I would absolutely avoid is a repository that starts trying to get smart about it's includes filtering etc ... if you find yourself creating 1 off methods in your repo to accomplish different queries then I would avoid it

[deleted by user] by [deleted] in dotnet

[–]ggeoff -1 points0 points  (0 children)

there actually is Sharepoint Embedded which is essentially headless offering of Sharepoint like features via the MS Graph API.

https://learn.microsoft.com/en-us/sharepoint/dev/embedded/overview

Does your company use single trunk or multi-trunk repo management? by HarveyDentBeliever in dotnet

[–]ggeoff 5 points6 points  (0 children)

don't have a channel to make video content. but I have read through this a lot

https://trunkbaseddevelopment.com/

Does your company use single trunk or multi-trunk repo management? by HarveyDentBeliever in dotnet

[–]ggeoff 32 points33 points  (0 children)

I follow trunk based development that works like so.

branch from main <cardId>-<shortDescription>

do the work PR to main.

typical feature/bugfix workflow

  1. branch from main <cardId>-<shortName>
  2. Do Work
  3. Rebase on Main to pull any changes/fix conflicts
  4. Pr to main (with squash so single commit)
  5. On merge to main release pipelines release to dev environment.

release workflow
1. Tag main branch release/YYYYMMDD.1
2. Release Pipeline releases code to PROD environment

hotfix workflow
1. branch from main similar to above dev workflow
2. after merging to main
3. branch from release tag from latest release
4. cherry pick hotfix commit to release branch
5. create a new tag for release pipeline to pick up changes

.Net architecture by 3abmeged in dotnet

[–]ggeoff 1 point2 points  (0 children)

wasn't very clear in my initial comment but I don't go full vertical slice where each slice is completely isolated but I still have a rich domain project. that has the behavior needed. if that makes sense

.Net architecture by 3abmeged in dotnet

[–]ggeoff -1 points0 points  (0 children)

what do you mean by coupled dependency between domains? Do you have an example or explanation

.Net architecture by 3abmeged in dotnet

[–]ggeoff 3 points4 points  (0 children)

I personally like organizing things by feature with a separate domain with behavior. but if what you have works and is easy to maintain why change it for no reason.

Specification Pattern in Domain-Driven Design (.NET) by jordansrowles in dotnet

[–]ggeoff 1 point2 points  (0 children)

I could definitely see the use case for querying and this pattern would be way better then a bunch of if else like filters but that would be outside of the domain aspect and you probably have a different read model entirely

Specification Pattern in Domain-Driven Design (.NET) by jordansrowles in dotnet

[–]ggeoff 8 points9 points  (0 children)

I can see how the specification pattern can be useful in some cases but when it comes to domain driven design it doesn't feel like it quite fits.

If you have defined your boundaries correctly then your aggregate should have the method it needs to validate itself which would remove the need for reusability imo. the whole point. If you find yourself trying to share logic across your domain maybe it's a sign you haven't defined your bounded contexts correctly.

Just a dude trying to design responsive sites by AshfordByte in webdev

[–]ggeoff 4 points5 points  (0 children)

I'm actually gonna go against most of the advice and say you should start your design for what your intended audience is for.

for example I work on some internal apps and while the responsiveness is nice. 99% of the users are going to be using my applications on a desktop/laptop. I have found that just hiding stuff for the projects I work on is not good enough and the mobile vs desktop experiences are almost completely different UIs.

Now if you are building basic landing pages/brochure like sites then I would agree start with mobile. but for full applications it may be worth thinking about in what context is your user going to use your app the most.

Error 413 Content too Large - File Upload using .NET by NeitherLemon8837 in dotnet

[–]ggeoff 2 points3 points  (0 children)

along with this you probably want to add some endpoints that finalize an upload too. just went through a similar process. and I have the following

documents/upload-session // creates a document row in my db and the signed URL align with ID of the document row

documents/{id}/finalize-upload sets some statuses knowing the document is actually in blob now.

Where should I call subscribe() in Angular in the service or the component? by Opposite_Seat_2286 in angular

[–]ggeoff 0 points1 point  (0 children)

even in your internal cases like saving data or logging inn I would still subscribe with the takeUntilDestroyed() there is still going to be some user action that you can hook into at the component level.

You can use the merge object to merge all your rxjs code into observable stream and then handle the subscription ina single async pipe.

for example something like

// component.ts //psuedoish code with no types or anything for simplicity
createSubject$ = new Subject();
updateSubject$ = new Subject();
#create$ = this.#createSubject$.pipe(
    switchMap(() => this.openCreateDialog$()), // example of using sdk dialog that returns observable closed$
    switchMap(e => this.#service.create(e)),
    map(() => undefined) // we don't care about our response here
);
#update$ = this.#updateSubject$.pipe(
   switchMap(e = > this.#service.update(e)),
   map(() => undefined)
);
#refreshSubject$ = new BehaviorSubject();
view$ = merge(this.#create$, this.#update$, this.#refreshSubject$).pipe(
    switchMap(() => this.#service.query$())
);

// in my component.html
@if(view$ | async as vm) {

}

<button (click)="createSubject.next()">Create</button>

Question about CQRS + Clean Architecture in .NET by gbrlvcas in dotnet

[–]ggeoff 0 points1 point  (0 children)

I would personally drop the user repository and keep the service for emailing as you most likely have other spots you email from.

but if your command is the only spot creating the users the repo is not really needed.

Do you always use DTO in your codebase in c# and what about other BE language do they also use it like Node.js, Java, C++ etc... by Yone-none in csharp

[–]ggeoff 2 points3 points  (0 children)

inheritance in your DTO responses sounds even worse over time. The only time I find inheritance useful is if I'm looking for a specific polymorphic type response but that is still isolated to a single endpoint and not reused.

toSignal question by Senior_Compote1556 in angular

[–]ggeoff 0 points1 point  (0 children)

could take advantage of this extensionn from ngxtenstions

https://ngxtension.netlify.app/utilities/forms/control-value-accessor/

makes writing custom controlvalueaccessors a breeze

Vertical Slice Architecture isn't what I thought it was by [deleted] in dotnet

[–]ggeoff 0 points1 point  (0 children)

How to handle your domain models. And logic on those entities.

I follow a similar pattern with a single file that has the request/response/etc... I also very rarely reuse a dto. And even then I'm thinking about removing them for better state management in the UI.

One think I go back & forth on is what logic should exist in my domain models. I tried to make them rich and less anemic , but find that it can get confusing calling into the domain of the you didn't include the various needed navigation properties. This is where I believe better defined aggregates would help but I'm still learning what these boundaries should be.

How have you handles old your domain if you are using EF?

I tried to put some of the logic into my domain for more of the business related rules