It depends. I'm sure that's what they would tell you in the Oracle training class. :)
For starters Oracle recommends two diskgroups named DATA and FRA. If you are using RAC then you will probably create a third diskgroup named CRS.
The redundancy level depends on your storage. If the storage array is providing RAID protection, then you can configure the ASM diskgroups with External Redundancy. But, this is not always the case. You might want to mirror between an external SAN and in internal ioDrive using ASM Normal Redundancy and then set the parameter asm_preferred_read_failure_groups to ensure all reads come from the flash drive. So you see there are countless possibilities that make us say "it depends".
In larger organizations with Enterprise Storage it is rarely so simple. Recall that a diskgroup is a collection of like storage. If you have LUNs of different sizes and performance levels, then you should group the LUNs according to those attributes. Each grouping becomes a diskgroup. For example, never mix RAID 5 LUNs from a Clariion with RAID 5 LUNs from a Symmetrix, and never mix any of those with RAID 10 LUNs. Also, within a diskgroup you want all storage of the same size due to the impact on striping and mirroring. This is all discussed in the Oracle on-line documentation.
If your storage team carves up the array into different classes of storage, then you will probably want to create separate ASM diskgroups. The I/O profiles are completely different for log files versus datafiles, and a well trained storage admin knows how to address each case. So now, if the storage admin gives you high performance LUNs designed for redo logs, lower performance LUNs marked for archivelogs, and a third set of LUNs marked for datafiles, then you will want to create three separate ASM diskgroups named DATA, REDO, and FRA to isolate the storage based on performance characteristics.
Often times with Enterprise Storage you cannot avoid I/O conflicts, so there's no point in separating Oracle's files into their own diskgroups (data, index, redo, etc.) Back on the array you will find the stripes overlay each other. And the array internally ties the storage devices together with either copper or fiber loops, so the I/O's are getting mixed and competing for resources. All I am saying is talk to your storage team and see if they think it will make any difference to try separating tables and indexes into different files given the way they setup the array.
For a small 1 TB database like yours I generally use two ioDrive 1.2 TB PCIe flash memory cards and create one ASM diskgroup named DATA with Normal Redundancy. Bang, done. RAID 10 protection at 5x the performance of a well tuned SAN, and I don't have to wait two weeks for the Enterprise Storage team to carve up LUNs. This takes a great load off the SAN and helps the other enterprise users with their performance issues, and frees up capacity thereby extending the life of the enterprise storage.
The above "answers" are a very generic introduction to planning ASM storage. If you have more specific questions, let us know.