DDD and Testing Example

[dshunfen]

I love the idea behind this and the idea here to both maintain typing but separating business logic. And I see it's explicitly pointed out that the project:

Facilitates easier testing and maintainence of business logic

It would be great to see some examples of testing the domain logic in the example project.

The way I'm seeing the mapping of this project on to DDD/Clean/Hexagonal principles is that:

• The loader and action functions act as the abstraction layer for the core domain logic. Meaning, only the business logic using domain entities (hiding implementation-specific details) should exist there
• The domain-function type and zod validation are essentially the interface (i.e. port)
• The implementation in the domain-function itself is the real infrastructure-specific low-level logic (i.e. adapter)

Is the above a correct assessment?

I'd like to understand how to be able to use different "adapters" for the domain-function ports.
For example, here in your example app:

// The output of getUser will be the input of formatUser
const getData = pipe(getUser, formatUser)

export const loader = async ({ params }: LoaderArgs) => {
  const result = await getData(params)
  return loaderResponseOrThrow(result)
}

It would be a big win for me (and would really hit home the intention of this project) to see a unit test added to this example that tests the core business logic in the loader and swaps the "adapter" domain-function which currently makes a call to 'https://jsonplaceholder.typicode.com' and instead invokes another domain-function adapter which is either a mock or pulls the user from a DB/Cache/etc.

[gustavoguichard]

Hi @dshunfen , thank you for reaching out!
I'm not entirely sure I got what you expect from the tests but I'll definitely gonna be adding tests to the example folder whenever I get some spare time.
That said you're welcome to contribute with a PR. Be there as it may, tests, another example, etc.

There are people using DF in various contexts: backend, bff, and frontend of different kinds so I feel like adding more examples to that folder as well.

[dshunfen]

@gustavoguichard Thanks for this!

Would be happy to take a stab at the unit tests. Do you think you could give me an idea on how you would approach it?
Very cool to hear that people are using DF in so many other contexts, too.

[gustavoguichard]

Yeah, I've used it in Remix, Next, Express, and Astro and I've heard about people using it in all of the above + Firebase functions, AWS lambdas, Vue + Nuxt ☺️

I'll reply later with an example of DF tests. But basically the DFs can be tested almost as pure functions (unless there's something like fetch, DB interactions, and other side effects in it), we mock whichever external interfaces or use a testing DB and we test the happy path with fromSuccess helper - and the unhappy path without it by checking result.errors/envErrors/inputErrors .

I'm AFK now, will get back to you soon ;)

[diogob]

@dshunfen I would be careful not to take the DDD / ports and adapters analogy too far. These were inspirational, but this library was not an attempt to implement them "as is".

The main idea is to enable a standard representation for business logic (DomainFunction type) and easy composition so you are able to swap parts without adding a lot of tests.

Now to your points:

• Personally I see loader and action just as another adapter, gluing your DFs to the outside world.
• The DomainFunction type and zod validation are indeed the interface (or port).
• The implementation of DFs will contain your core business logic. It can be more or less infrastructure agnostic. It depends on your personal style. I rather start with the infrasctructure code embedded in the domain and use mocks to test. However, you could carve infrastructure related code into separate DFs (with your pardon for fuzzy boundaries in our terminology) and swap them using a pipe.

I hope I have not created more confusion. I believe @gustavoguichard 's example on testing will shed more light on our style of testing. It does not mean you cannot create your own ;)

[dshunfen]

@gustavoguichard @diogob Thank you both for the thoughts. I'm realizing now this really belonged in the Discussion section rather than Issues for others to benefit from. May be good to move this there.

I like what I'm hearing, and what you're saying is definitely clarifying rather than confusing.

Totally see what you mean and agree with these two points from my perspective:

• Personally I see loader and action just as another adapter, gluing your DFs to the outside world.
• The DomainFunction type and zod validation are indeed the interface (or port).

The last point:

• The implementation of DFs will contain your core business logic. It can be more or less infrastructure agnostic.

There's two ways I've thought about approaching using DF's (pardon my pseudocode):

1. In the approach I see in the example folder, each DF has the infra-specific implementation. That is, for example, a listUser DF has remix/cookie Session retrieval code and then makes a Prisma DB call to postgres. I think this approach is where I'm having trouble seeing how adapter-swapping and testing would look like:

   const getSession = mdf(zod.object)(((args, context) => {
      return cookie.session.getSession();
   })
   const getUsers = mdf(zod.object)(((args, context) => {
      return prisma.getUsers(org: args.org.id);
   })
   const listUsers = pipe(getSession, getUser);
   
   export async function loader({ request, params, context }: LoaderArgs) {
     const result = await listUsers(params)
     return loaderResponseOrThrow(result)
   }

2. The other approach I'm considering is using DF's kind of like a "middleware", which contain the business logic. I would just need one DF per action/loader per route, and mainly use the DF for the zod validation and JSON result translation. I'd essentially have two abstractions; one is the DF itself, and inside of it is the business logic "ports" usage as an abstraction over the implementation details. To demonstrate, this would look something like:

   const listUsers = mdf(zod.object)(((args, context) => {
      const session = ISessionService.getSession(); // This would call a SessionServiceImpl, which could be Supabase, a mock, etc.
      return IUserService.getUsers(session.org.id); // This would call a UserServiceImpl, which could be Supabase, a mock, etc.
   })
   
   export async function loader({ request, params, context }: LoaderArgs) {
     const result = await listUsers(params, context) // Using this technique, I'd generally only have one DF
     return loaderResponseOrThrow(result)
   }

   Using this approach, I'd have the domain abstraction under the DF. I like this because I'm more used to this technique and I can more easily conceptualize this with the way I've seen/used DDD in the past. However, I get the feeling you don't intend the lib to be used this way.

Again, thanks for the conversation. Would love to hear your opinions on these two approaches.

[diogob]

@dshunfen I believe both examples are good in their own style. I gravitate more towards the first one since I rather use DFs all the way down keeping fewer concepts in my head.

Regading the adapter swapping, in the example it would not make a lot of sense since there is very little logic in the DFs (the pipe does most of the job).

But let's consider an example with some conditional logic:

const makeGetSession = mdf(zod.object());
const getSession = makeGetSession(((args, context) => {
   return cookie.session.getSession();
})

const authorizeUser = mdf(zod.object(), zod.object())(((args, context) => {
  if(!context.admin)
    throw new NotAuthorizedError();
  return args.org.id;
})

const makeGetUsers = mdf(zod.object({ org: z.object({id: z.number()}) }))
const getUsers = makeGetUsers(((args, context) => {
   return prisma.getUsers(org: args.org.id);
})
const listUsers = pipe(getSession, authorizeUser, getUser);

Note that I also have extracted the first bit of the DF definition that takes the parsers just to simplify the following example.
Now I can test authorizeUser with DFs that use the same parsers but have a different implementation:

const getSessionMock = makeGetSession(((args, context) => {
   return { org: { id: 1 } };
})

const getUsersMock = makeGetUsers(((args, context) => {
   return [];
})

const listUsersWithMocks = pipe(getSessionMock, authorizeUser, getUserMock);

Just keep in mind that these are all didactic examples. Beware of extracting functions too early so you won't get a soup of unintelligible DFs.

[dshunfen]

Thank you for this!