As game designer, that is up to you.
The End.
Alright, alright... Ask yourself how do you want the game to be played. Ask yourself how should the player react with the results of combat. Then, for each aspect of your combat mechanic consider how it supports those play styles and whatever or not it justifies reactions you do not want.
It can be helpful to reduce the mechanic to its minimum. In this case, it would be whoever attacks wins. Is that good for your game? Maybe, but probably not. You seem to want troops, you probably want the players to make them... however, if they don't affect the result of combat, this design does not support any play style that involve making troops.
So, we want a design that encourages to make troops. That means that the more troops the better. Then the simplest design is that whoever has more troops wins. So the player will want to send more troops than the enemy. That is viable.
How about types of troops? You could have some troops have more weight than others. You could have some troops be better when attacking than defending.
Do you want players to pick the best troop possible and then just do a bunch of that one? If not, then you need to give incentive to create different kinds of troops. Perhaps some troops have synergies and count as more when they are together. Or perhaps some troops have diminishing returns, so at some point it does not make sense to add more of the same kind.
Now, we are getting somewhere. You need a function that takes the army and gives it a score for attack, and a score for defense. And you can put there whatever. Yes, the number of troops of each kind, but also buffs, terrain, time of the day, etc.
Oh, I forgot, a common trope is to have some kinds troops have advantage over other kinds of troops. In a rock-paper-scissors fashion. Which can be the foundation of rotating meta. If you want to do that, then the score needs to consider the both armies... so, yeah.
I do not know what buffs exist in your game, or what terrains, or even if there is a day cycle... you know, so you have to make up this function. You, as game designer, tweak it for your needs. It is art and engineering, not science.
Ah, something else you need to decide: are the result just win or lose, or can you have results like they loss x amount of troops, or even they earned experience. Do troops have levels? In some games yes, in some games no.
Here is an idea: you could have hero units, they could be the only ones with experience, and gain levels. They could even have equipment. Now it is an strategy game and an RPG.
And one more thing: are the results deterministic? You can, for example, use the score of the army as a mean metric for a bell curve, with some (hand tweaked by you, the designer) standard deviation, so that the army sometimes performs a little better, some times a little worse. And why should it be a bell curve? It can be whatever.
Should a single unit be able to defeat a large army just by chance? Ern... probably not. Unless that is what you are going for, players are likely to want to feel in control.
What I describe above is output randomness (the player set all the thing the best they can, and then RNGesus comes and messes with the result).
You can convert that into input randomness. That is, the game tells the player that if they attack they will have x random buff. Now, the random happens before the player decides.
You can go further. Perhaps the player has a deck of card, and each attack one is pulled at random. Now it is an strategy game and a deck building game.
OK, so you come up with some model, how do you know if it is right? YOU TEST!
If it does not work, if player react in ways you don't want (be that as evident as rage quit or in more subtle ways), or if the play styles you want are not viable or do not make sense with the given mechanic... well, you go back and tweak it.
Which reminds me. You do not need to have final art to test the mechanic. Heck, you do not need to put the mechanic into the game to test it, you can do an isolated prototype. In fact, some mechanics can be tested with pen and paper, which could make sense in early stages when you yet don't know if it worth the trouble to program the mechanic.
There is another aspect of this, and that is conveying the mechanic to the player. In general, the player does not need to know the details of how these mechanics work in a particular game. However, the game should teach how to play it. And that means that the game got to convey how it works to some degree. The game does not have to tell the player that the army attack score is such and such function of the troops. Yet, convey that more troops means better.
It could be useful for you to play those games with the intent of analyzing them from the point of view of game design. In particular see what are they doing to convey their mechanics. Not only to have a hint of how they work, which is directly applicable to your problem. But also to see what play styles are they encouraging.
All in all, remember that I do not know what is in your game. Furthermore, I cannot tell you what should be in your game. I cannot design the game for you. If you just wanted games designed by other people, you would not be doing this, right? Perhaps, what your game needs is precisely to not do it like everyone else.
As game designer, that is up to you.
The End.
game-designtag —we've shared some tips there about how to ask a focused and constructive game-design question, by giving background to how your game works currently, and clearly articulating your target experience with examples, as Philipp says. \$\endgroup\$