I'm sorry, in advance, for the rambling nature of my commentary.
I want to use one domain for all of the users without subdomains. Am I right? Actually I don't see the advantage of using more domains, not even subdomains.
Single-domain is nearly always the way to go for organizations of almost any size, large or small (especially since Microsoft added fine-grained password policy). Single-domain is the easiest configuration to administer, by far.
Domain Controller Computers
If there are local resources that users in each physical office can access to keep working in the event of WAN failure then putting a Domain Controller (DC) in every physical office is certainly nice. If all the resources they access are remote anyway then it might not make sense to deploy so many DCs.
If your plan is to use the DC in each office as a file server, too, I'd strongly recommend using Hyper-V to host the DC as a separate VM guest. You should try to isolate DCs to providing domain-related services and nothing else, if at all possible. It decreases your attack surface.
Think about what happens if somebody steals a DC from one of the offices and plan for that. You should read-up on Read Only Domain Controllers (RoDC) to see if it fits the bill for your needs. If an RoDC gets stolen the passwords on that RoDC are compromised. If a traditional read/write DC gets stolen all passwords (and the
krbtgt hash) are compromised and you will need to reset all passwords (and reset the
krbtgt hash and reboot all the domain member computers).
Sites, Subnets, Replication
You'll want to configure Sites and Subnets to allow AD to properly manage the replication topology.
Can I replicate only subtrees between DCs? Like "OU=country1, OU=Internal, CN=Users"?
Don't worry about any selective replication of AD. You have so little data that any attempts to selectively replicate (which is what child domains are about, primarily) will just cause a lot more grief than benefit.
Be aware that intersite replication latency (15 minutes between sites, by default) will make you want to get in the habit of connecting your remote administration tools directly to the DC in an office when you want to make changes that are immediately "visible" to users in that site. (There is an option to enable a change notification protocol for intersite replication that will speed replication dramatically, but that's not the default behavior of the product.)
Delegation of administrative control is the first design constraint you should use in determining an OU structure. For example, if there will be users in each remote office who can act as "helpdesk" and reset passwords for local users then you'll want a geographically-oriented OU structure (as you've proposed). In some companies the OU structure breaks down first by departmental / business-unit lines because delegated administration is handled at the departmental / business-unit level. Even if you're not planning for any delegation of control now think about how the company might grow in the future and try to plan for that. (Geographic is generally the way people go.) Delegation of control amounts of access control lists (ACLs) applied to objects in the directory. Since an object can only have a single ACL applied, and since it inherits its ACL from the container (OU, in most cases) it's placed into, by default, the getting the location of the object is pretty important.
The second design constraint should be application of Group Policy. Since you're new to AD you should take some time to read-up on Group Policy. Unlike delegation of control, Group Policy is more flexible about applying to objects that are "spread out" in subordinate containers (through a feature called "Security Filtering"), so it's less critical that your OU structure reflect your planned Group Policy application strategy (though, when you can just link GPOs to OUs without any security filtering things are much simpler).
I saw somewhere an AD where they didn't use the CN=Users for the "normal" users, but a new CN="Company Users" in the root. Is it a common convention? I don't see any good reason to don't use the original CN=Users subtree.
The practical reason is that the "CN=Users" object is a "Container" object (not an OU-- compare the difference in the icons in "Active Directory Users and Computers" to "Users" versus "Domain Controllers") and cannot have Group Policy applied to it, nor can it have OUs created beneath it. The same holds true for the "CN=Computers" container. Practically speaking, nobody who uses Group Policy uses these containers for anything other than the default user accounts and groups placed in "CN=Users" (which, in general, you shouldn't move!).
You can't create the OU structure you're looking for below "CN=Users" because you're not allowed to create OUs there. The typical convention is to create a domain-level OU and place all your OUs, users, computers, groups, etc, under that OU.
It looks like you're off to a solid start, but I'd spend some time playing with this in a lab and thinking about common administration scenarios. Spend a little money and time on reading about AD in general and Group Policy, in particular, and I think you'll have a reasonable time of it.